qmail labeling

[Kristen Reitz]

List

	I have had some trouble with qmail and SELinux. Following my  
installation of qmail and running restorecon on the /var/qmail  
directory tree I ran into AVC denial messages upon reboots.

When my server boots the smart daemon is trying to send mail stating  
that I have a drive which is failing. (true, it's the one that caused  
me to have CentOS 5.2 on a new drive). The smartd error messages follow:

Jul 24 14:31:39 host smartd[2598]: Monitoring 2 ATA and 0 SCSI devices
Jul 24 14:31:39 host smartd[2598]: Device: /dev/hdb, FAILED SMART  
self-check. BACK UP DATA NOW!
Jul 24 14:31:39 host smartd[2598]: Sending warning via mail to root ...
Jul 24 14:31:39 host smartd[2598]: Warning via mail to root produced  
unexpected output (32 bytes) to STDOUT/STDERR:  qmail-inject: fatal:  
read error
Jul 24 14:31:39 host smartd[2598]: Warning via mail to root: successful
Jul 24 14:31:39 host smartd[2598]: Device: /dev/hdb, 1522 Currently  
unreadable (pending) sectors
Jul 24 14:31:39 host smartd[2598]: Sending warning via mail to root ...
Jul 24 14:31:39 host smartd[2598]: Warning via mail to root produced  
unexpected output (32 bytes) to STDOUT/STDERR:  qmail-inject: fatal:  
read error
Jul 24 14:31:39 host smartd[2598]: Warning via mail to root: successful
Jul 24 14:31:39 host smartd[2606]: smartd has fork()ed into  
background mode. New PID=2606.

Below is the reason for the fatal read error which is listed above as  
being successful, but isn't. (AVC message not specific to the above  
smartd error, it's just one of many related to the smartd error)

type=AVC msg=audit(1215375080.575:15): avc:  denied  { read } for   
pid=2585 comm="qmail-inject" name="me" dev=dm-4 ino=3170476  
scontext=system_u:system_r:system_mail_t:s0  
tcontext=user_u:object_r:var_t:s0 tclass=file
type=SYSCALL msg=audit(1215375080.575:15): arch=40000003 syscall=5  
success=no exit=-13 a0=804e45b a1=800 a2=0 a3=bfe68128 items=0  
ppid=2584 pid=2585 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0  
egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="qmail-inject"  
exe="/var/qmail/bin/qmail-inject"  
subj=system_u:system_r:system_mail_t:s0 key=(null)

The "me" file is in the /var/qmail/control/ directory, a directory  
which hasn't any content labeling when I view a recent strict policy  
file.

/var/qmail/bin(/.*)?    system_u:object_r:bin_t:s0
/var/qmail/supervise(/.*)?      system_u:object_r:svc_svc_t:s0
/var/qmail/supervise/.*/run     --       
system_u:object_r:svc_run_exec_t:s0
/var/qmail/supervise/.*/log/run --       
system_u:object_r:svc_run_exec_t:s0
/var/qmail/rc   --      system_u:object_r:bin_t:s0
/var/qmail/bin  -d      system_u:object_r:bin_t:s0
/var/qmail/bin/sendmail --      system_u:object_r:sendmail_exec_t:s0

The problem is when the system boots, the smartd finds my bad drive  
and tries to email me about it. No emails arrive and I find rather  
messages in my audit log. I ran audit2why to study this, then  
audit2allow to create te rules. Below are the rules created which I  
have implemented.

allow system_mail_t var_t:dir { write remove_name add_name };
allow system_mail_t var_t:fifo_file write;
allow system_mail_t var_t:file { write getattr link read create  
unlink };

I now received email ( 2 messages total ) from the smartd following a  
reboot. The question I have is this. Should I even be making allow  
rules at all? Should not the policy file have the right labeling for  
a qmail install? And since it appears to me it does not, should I be  
making a policy file which I can then use restorecon to adjust my  
system labeling with? Or are type enforcement rules truly the way to  
go? I must admit I am new to SELinux and it's management so this is  
all about learning. I am not seeking a 'fix' so much but rather an  
understanding leading to a proper fix. I have read that relabeling  
has security risk and should be avoided entirely. Perhaps that's  
another subject all together?

Kristen