Bug 429843 - [exim] denials when sending from cronjobs
[exim] denials when sending from cronjobs
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: exim (Show other bugs)
5.1
All Linux
low Severity low
: rc
: ---
Assigned To: Miroslav Lichvar
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-23 07:53 EST by Enrico Scholz
Modified: 2009-03-26 21:24 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-26 21:24:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Enrico Scholz 2008-01-23 07:53:38 EST
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
Comment 1 Daniel Walsh 2008-01-23 16:38:07 EST
Does email get sent?

What is main.log?

Does exim want to write to /var/spool/input?

Comment 2 Enrico Scholz 2008-01-23 19:23:19 EST
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).
Comment 3 Daniel Walsh 2008-01-24 14:32:15 EST
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(/.*)?'
Comment 4 Enrico Scholz 2008-01-30 09:08:02 EST
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.
Comment 5 Daniel Walsh 2008-01-31 11:49:44 EST
Fixed in /selinux-policy-2.4.6-118.el5	
Comment 6 RHEL Product and Program Management 2008-01-31 11:56:19 EST
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.
Comment 11 Eduard Benes 2008-02-22 05:42:40 EST
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 
Comment 12 Eduard Benes 2008-02-22 05:51:58 EST
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
...
Comment 13 Petr Šplíchal 2008-02-22 06:02:16 EST
this snippet from /var/log/exim/main.log could perhaps help to locate the problem:

internal problem in userforward router (recipient is
root@x86-64-5c-1-m1.lab.boston.redhat.com): failure to transfer data from
subprocess: status=0000 readerror='Permission denied': error=failed to stat
/root/.forward (Permission denied)

== root@x86-64-5c-1-m1.lab.boston.redhat.com R=userforward defer (-1): internal
problem in userforward router (recipient is
root@x86-64-5c-1-m1.lab.boston.redhat.com): failure to transfer data from
subprocess: status=0000 readerror='Permission denied': error=failed to stat
/root/.forward (Permission denied)
Comment 14 Daniel Walsh 2008-02-22 09:35:54 EST
Fixed in selinux-policy-2.4.6-123
Comment 16 Petr Šplíchal 2008-03-11 09:06:43 EDT
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/
Comment 17 Daniel Walsh 2008-03-11 19:51:47 EDT
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.
Comment 19 Thomas Woerner 2008-03-14 10:43:14 EDT
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.
Comment 20 Daniel Walsh 2008-03-14 11:09:52 EDT
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.

Comment 21 Petr Šplíchal 2008-03-14 11:19:43 EDT
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?
Comment 22 Daniel Walsh 2008-03-14 11:29:28 EDT
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?
Comment 23 Thomas Woerner 2008-03-14 11:45:46 EDT
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.
Comment 24 Petr Šplíchal 2008-03-14 11:54:16 EDT
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.
Comment 25 Daniel Walsh 2008-03-14 12:07:26 EDT
Is the inability to read the .forward file breaking exim?  IE Should it just
ignore the permission denied?
Comment 26 Thomas Woerner 2008-03-14 12:42:03 EDT
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.
Comment 27 Petr Šplíchal 2008-03-17 05:28:20 EDT
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?
Comment 28 Daniel Walsh 2008-03-17 09:47:14 EDT
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.
Comment 33 Josef Kubin 2008-04-08 10:34:12 EDT
It's candidate for me.
Comment 39 Josef Kubin 2008-04-10 11:20:44 EDT
exim should be fixed, not selinux-policy
Comment 41 Denise Dumas 2008-04-14 09:49:33 EDT
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? 
Comment 42 Daniel Walsh 2008-04-14 15:26:52 EDT
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.
Comment 43 Petr Šplíchal 2008-04-15 05:20:45 EDT
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!
Comment 44 Daniel Walsh 2008-04-15 09:45:00 EDT
Why do you need to setup .forward file in a homedir, Why not have the email sent
directly.
Comment 46 Jarkko 2008-04-29 05:06:37 EDT
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.
Comment 47 Phil Radden 2009-01-17 09:25:59 EST
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?
Comment 48 Phil Radden 2009-01-17 09:32:50 EST
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
Comment 49 Daniel Walsh 2009-01-19 15:50:16 EST
What policy version are you seeing this with?

rpm -q selinux-policy
Comment 50 Phil Radden 2009-01-19 17:43:19 EST
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)
Comment 51 Daniel Walsh 2009-01-20 11:02:24 EST
Could you try out the 5.3 policy.

Preview available on 

http://people.redhat.com/dwalsh/SELinux/RHEL5
Comment 52 Phil Radden 2009-03-14 17:19:50 EDT
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.
Comment 53 Daniel Walsh 2009-03-16 10:51:36 EDT
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.
Comment 54 RHEL Product and Program Management 2009-03-26 12:49:52 EDT
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 "?".
Comment 55 Daniel Walsh 2009-03-26 21:24:01 EDT
If you want this setup you will need to write custom policy.

Note You need to log in before you can comment on or make changes to this bug.