qmail labeling
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