Description of problem: There seems to be a problem, when exim is the default mailer and cron tries to send messages: avc: denied { write } for pid=16357 comm="sendmail" name="input" dev=dm-0 ino=160489 scontext=root:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_spool_t:s0 tclass=dir avc: denied { append } for pid=16357 comm="sendmail" name="main.log" dev=dm-0 ino=224700 scontext=root:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file avc: denied { append } for pid=16357 comm="sendmail" name="main.log" dev=dm-0 ino=224700 scontext=root:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file Mail is sent to remote recipient by setting | MAILTO=admin@foreign-site in /etc/crontab Version-Release number of selected component (if applicable): selinux-policy-targeted-2.4.6-106.el5_1.3 exim-4.63-3.el5 vixie-cron-4.1-72.el5
Does email get sent? What is main.log? Does exim want to write to /var/spool/input?
I can not say, whether email was sent (ordinary logwatch mail from cron.daily arrives, but I guess output above is from the '| mail ...' pipe from cron). main.log is /var/log/exim/main.log yes, exim creates file(s) in /var/spool/exim/input (note the /exim/ subpath).
If you execute chcon -R -t mail_spool_t /var/spool/exim chcon -R -t sendmail_log_t /var/log/exim Does that eliminate the avcs? If yes you can make the labeling permanent by adding. # semanage fcontext -a -t mail_spool_t '/var/spool/exim/(.*)?' # semanage fcontext -a -t sendmail_log_t '/var/log/exim(/.*)?'
yes; AVCs disappeared and mail arrives (it was a | Subject: Cron <root@...> run-parts /etc/cron.daily | | /etc/cron.daily/logrotate: | | error: stat of /var/log/maillog failed: No such file or directory | ... one). Now, a new | audit(1201662125.275:124): avc: denied { fowner } for pid=19752 comm="sendmail" capability=3 scontext=root:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=root:system_r:system_mail_t:s0-s0:c0.c1023 tclass=capability is generated.
Fixed in /selinux-policy-2.4.6-118.el5
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
It is not a labeling problem. There seems to be a typo in the rule to set the context on the exim log files: /var/log/exim.log.* all files system_u:object_r:sendmail_log_t:s0 Adding new file-context for exim log files to label them with sendmail_log_t solved the problem with log files: #semanage fcontext -a -t sendmail_log_t "/var/log/exim(/.*)?" # restorecon -R -v /var/log/exim restorecon reset /var/log/exim context system_u:object_r:var_log_t:s0- >system_u:object_r:sendmail_log_t:s0 restorecon reset /var/log/exim/main.log context system_u:object_r:var_log_t:s0- >system_u:object_r:sendmail_log_t:s0 restorecon reset /var/log/exim/panic.log context system_u:object_r:var_log_t:s0->system_u:object_r:sendmail_log_t:s0 # ll -Z /var/log/exim/ -rw-r----- exim exim system_u:object_r:sendmail_log_t main.log -rw-r----- exim exim system_u:object_r:sendmail_log_t panic.log Log showing presence of the bug before adding the new file-context: # mdadm --manage --set-faulty /dev/md3 /dev/loop4 mdadm: set /dev/loop4 faulty in /dev/md3 # ausearch -m AVC -sv no -ts 5:05:25 | audit2allow #============= system_mail_t ============== allow system_mail_t var_log_t:file append; # restorecon -R -v /var/log/exim # rpm -q selinux-policy selinux-policy-2.4.6-122.el5.noarch # semanage fcontext -l | grep exim /var/log/exim.log.* all files system_u:object_r:sendmail_log_t:s0 /var/spool/exim(/.*)? all files system_u:object_r:mail_spool_t:s0 /usr/sbin/exim regular file system_u:object_r:sendmail_exec_t:s0
After changing the file-context as described in the previous comment new AVC denials appeared. Any idea what could trigger them? # ausearch -m AVC -sv no -ts 5:32:02 | audit2allow #============= system_mail_t ============== allow system_mail_t home_root_t:dir search; allow system_mail_t self:fifo_file { read write }; .qa.[root@x86-64-5c-1-m1 ~]# ausearch -m AVC -sv no -ts 5:32:02 ---- time->Fri Feb 22 05:32:58 2008 type=SYSCALL msg=audit(1203676378.760:14909): arch=c000003e syscall=4 success=no exit=-13 a0=55556578cd10 a1=7fffc63f7f50 a2=7fffc63f7f50 a3=0 items=0 ppid=1 pid=11458 auid=0 uid=0 gid=93 euid=0 suid=0 fsuid=0 egid=93 sgid=93 fsgid=93 tty=(none) comm="exim" exe="/usr/sbin/exim" subj=root:system_r:system_mail_t:s0 key=(null) type=AVC msg=audit(1203676378.760:14909): avc: denied { search } for pid=11458 comm="exim" name="home" dev=dm-0 ino=9666561 scontext=root:system_r:system_mail_t:s0 tcontext=system_u:object_r:home_root_t:s0 tclass=dir ---- time->Fri Feb 22 05:32:58 2008 type=SYSCALL msg=audit(1203676378.760:14910): arch=c000003e syscall=2 success=no exit=-13 a0=55556578cd10 a1=0 a2=1b6 a3=0 items=0 ppid=11458 pid=11459 auid=0 uid=12748 gid=12748 euid=12748 suid=12748 fsuid=12748 egid=12748 sgid=12748 fsgid=12748 tty=(none) comm="exim" exe="/usr/sbin/exim" subj=root:system_r:system_mail_t:s0 key=(null) type=AVC msg=audit(1203676378.760:14910): avc: denied { search } for pid=11459 comm="exim" name="home" dev=dm-0 ino=9666561 scontext=root:system_r:system_mail_t:s0 tcontext=system_u:object_r:home_root_t:s0 tclass=dir ---- time->Fri Feb 22 05:32:58 2008 type=SYSCALL msg=audit(1203676378.764:14911): arch=c000003e syscall=0 success=no exit=-13 a0=6 a1=7fffc63f829c a2=4 a3=0 items=0 ppid=1 pid=11458 auid=0 uid=0 gid=93 euid=0 suid=0 fsuid=0 egid=93 sgid=93 fsgid=93 tty=(none) comm="exim" exe="/usr/sbin/exim" subj=root:system_r:system_mail_t:s0 key=(null) type=AVC msg=audit(1203676378.764:14911): avc: denied { read } for pid=11458 comm="exim" path="pipe:[1411709]" dev=pipefs ino=1411709 scontext=root:system_r:system_mail_t:s0 tcontext=root:system_r:system_mail_t:s0 tclass=fifo_file ---- time->Fri Feb 22 05:32:58 2008 type=SYSCALL msg=audit(1203676378.764:14912): arch=c000003e syscall=1 success=no exit=-13 a0=7 a1=7fffc63f829c a2=4 a3=0 items=0 ppid=11458 pid=11459 auid=0 uid=12748 gid=12748 euid=12748 suid=12748 fsuid=12748 egid=12748 sgid=12748 fsgid=12748 tty=(none) comm="exim" exe="/usr/sbin/exim" subj=root:system_r:system_mail_t:s0 key=(null) type=AVC msg=audit(1203676378.764:14912): avc: denied { write } for pid=11459 comm="exim" path="pipe:[1411709]" dev=pipefs ino=1411709 scontext=root:system_r:system_mail_t:s0 tcontext=root:system_r:system_mail_t:s0 tclass=fifo_file ...
this snippet from /var/log/exim/main.log could perhaps help to locate the problem: internal problem in userforward router (recipient is root.boston.redhat.com): failure to transfer data from subprocess: status=0000 readerror='Permission denied': error=failed to stat /root/.forward (Permission denied) == root.boston.redhat.com R=userforward defer (-1): internal problem in userforward router (recipient is root.boston.redhat.com): failure to transfer data from subprocess: status=0000 readerror='Permission denied': error=failed to stat /root/.forward (Permission denied)
Fixed in selinux-policy-2.4.6-123
I suggest to solve mdadm mail (exim) denials (#335911) here as well, as part of the problem is purely exim-selinux issue which looks the same (or very close) to this one. Tested with mdadm-2.6.4-1.el5 and selinux-policy-2.4.6-125.el5. Mails still cannot be sent from mdmonitor using exim. I get this error in /var/log/exim/main.log: R=userforward defer (-1): failed to open /home/testuser/.forward: Permission denied (euid=500 egid=500) Testcase available in CVS & RHTS: mdadm/regression/bz335911-mdmonitor-mail-denial/
The problem with this is, we have a system mail program attempting to read a users home directory. I try to avoid this when ever possible. Since you use exim to mail the contents of a user home directory, from a confined domain that has been cracked into. exim when run by a user would work fine.
Using exim as a normal user, exim is delivering mail even with the command used by mdadm. There are no errors or warnings related to the recipients home directory or .forward file. Therefore this is not a exim problem. It seems to be a problem related to selinux.
RIght I don;t believe this is a real world problem. You had a cron job kicking off mdadm which was sending mail. This mail looked in a homedirectory for a .forward file. This is not allowed.
Daniel, can you please have a look at this? We've investigated the issue with Thomas and it seems there's no problem at exim's side. Perhaps if the mail was not being delivered locally (if mdadm would use exim daemon) could help to solve this. Or do you have any other idea?
Petr, Please explain exactly what is going on. Is the mail being delivered? mdadm is being setup to use exim as a mailer and it is looking in the users home directory for the .forward file?
Yes, sure. exim is always looking in the users home for a .forward and a .procmailrc to know if one of them should be used. As soon as mdadm is using the "sendmail -t", where sendmail is a link over alternatives to sendmail.exim, there is the problem with the users home. This is not a problem if a user is using the same command.
Ok: mdadm finds out about degraded array, tries to send an email (using exim), but exim is denied by selinux to deliver it, because it first looks for .forward in user home dir. You can run tests/mdadm/regression/bz335911-mdmonitor-mail-denial/ (in cvs) to see more details.
Is the inability to read the .forward file breaking exim? IE Should it just ignore the permission denied?
It is not good to ignore the erros, because the purpose of the files could be to forward the emails to another machine and/or user. Ignoring this error might also lead into other errors and the resulting error might not be in relation with the first problem and very hard to hunt down, then.
I don't think it is a good idea to have selinux set up so it prevents exim to look for .forward and/or .procmailrc --- as this is expected behaviour of MTA, isn't it? Or do I miss something?
The reason this is a difficult problem, is we are trying to stop a confined application from reading users home directories, if I allow a mail program to read a home directory, any confined domain that executes a mail program will be allowed to email contents of users home directories. I have not seen this problem with other mail programs (sendmail/postfix) needing to read users homedirs when executed from a system daemon, so I am questioning if this is a legitimate setup or just a configuration problem.
It's candidate for me.
exim should be fixed, not selinux-policy
For RHEL-5.2, the risk for this change in exim itself is way too high. The change proposed there would modify the basic behavior of a default exim installation in the last snapshots of the release. We need to implement this change and test it in Fedora first and then, assuming that it works properly with various configurations, we can aim for RHEL-5.3. In the meantime for RHEL-5.2, is some workaround from Dan possible? Or a release note?
Yes this should be in 5.3 if at all. This is probably not a real world situation, and if it happens it can easily be worked around by adding local policy.
Dan, I perhaps don't understand your definition of a "real world situation". It seems to me that it can very easily happen to a customer: I need a reliable file server, so I do just a minimal install of RHEL (which means exim as default email MTA), setup a RAID with mdadm and voilà: I get no emails about degraded arrays!
Why do you need to setup .forward file in a homedir, Why not have the email sent directly.
I'm not sure if you're talking about what I think you are, but here are my thoughts: It's very common that exim is configured to read ~/.forward when delivering mail to the user.* Denying this might not be a good idea. Exim does't have to read any other files from the user's home directory though - .forward will do. * The user can control .forward himself/herself. It is very common to support that. This way the user can configure mails to be forwarded to another server for example. Of course some administrators will choose not to support .forward, but if an administrator chooses to support it, it sounds like a weird idea to me, if also selinux policy must be tweaked then to make it work. Although... Exim should not read .forward when it's used as a mail sending command (e.g. if I use "echo test | mail user"). Only when exim receives an email as a server and is then delivering it to the user, it should read .forward. That behavior should naturally be allowed. (This might already work though because isn't that part of the delivery executed as the receiving user..? I'm not sure now though - at all.) But it sounds like the sending command tries to read .forward, and that is strange, if that is happening. Then it sounds like an exim bug to me.
Some additional simple test cases; for a fully updated EL5 system with exim as MTA supporting .forward files, a testuser crontab of * * * * * echo "hello world" results in ====== 2009-01-17 14:17:01 1LOByv-0001tj-FK <= testuser@localhost U=testuser P=local S=630 from <testuser@localhost> for testuser 2009-01-17 14:17:01 1LOByv-0001tj-FK == testuser@localhost R=forward_file defer (-1): failed to open /home/testuser/.forward: Permission denied (euid=500 egid=500) ====== However, the deferred mail then sits in the exim queue, and will be correctly delivered by the queue runner (if configured) later. A slightly tedious workaround is to use the following in the crontab instead: * * * * * echo "hello world" | mail testuser which works correctly. I'd be grateful if anybody could explain why the blocked .forward file access doesn't result in any avc alerts?
Sorry, quick addition; setting selinux to permissive enables the example in #47 to work as expected, and results in the following avc alert: avc: denied { getattr } for pid=7600 comm="exim" path="/home/testuser/.forward" dev=dm-1 ino=2261040 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=root:object_r:user_home_t:s0 tclass=file
What policy version are you seeing this with? rpm -q selinux-policy
selinux-policy-2.4.6-137.1.el5 selinux-policy-targeted-2.4.6-137.1.el5 $ /usr/sbin/sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 21 Policy from config file: targeted (policy contains a small local module giving some additional rights to clamd_t, but otherwise unmodified)
Could you try out the 5.3 policy. Preview available on http://people.redhat.com/dwalsh/SELinux/RHEL5
Apologies for pitifully slow response; neither the RPMs available at that time, nor the current latest (2.4.6-217) change the problematic behaviour. As mentioned in comment #48 there is an avc denied which shows up if selinux is permissive - why doesn't this show up when selinux actually blocks it? Other avc alerts appear as expected.
Because a previously blocked access would prevent the email from getting to the point of reading this file. In enforcing mode, exim is probably blocked from reading /home, and this may be dontaudited. So in enforcing mode exim will stop trying to read the .forward file when /home is blocked and will take a different code path or fail. In permissive mode it will be allowed to read /home and will eventually try to read the .forward file which does not have a dontaudit, and will generate the avc.
This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?".
If you want this setup you will need to write custom policy.