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
--
fedora-selinux-list mailing list
fedora-selinux-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Could you try to label the directory mail_spool_t
chcon -R -t mail_spool_t /var/qmail
If that fixes the problem, you could execute this command to make it
survive a relabel
semanage fcontext -a -t mail_spool_t /var/qmail(/.*)?