Kristen Reitz wrote:
> 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@xxxxxxxxxx
> 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(/.*)?
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
