Bug 919802

Postfix hits the same AVC as sendmail, but abrtd insists in filling it against sendmail not postfix


+++ This bug was initially created as a clone of Bug #673384 +++

SELinux is preventing /usr/sbin/sendmail.sendmail from 'read' accesses on the directory /home/dummy.

*****  Plugin catchall (50.5 confidence) suggests  ***************************

If you believe that sendmail.sendmail should be allowed read access on the dummy directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep newaliases /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

*****  Plugin leaks (50.5 confidence) suggests  ******************************

If you want to ignore sendmail.sendmail trying to read access the dummy directory, because you believe it should not need this access.
Then you should report this as a bug.  
You can generate a local policy module to dontaudit this access.
Do
# grep /usr/sbin/sendmail.sendmail /var/log/audit/audit.log | audit2allow -D -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                unconfined_u:system_r:system_mail_t:s0-s0:c0.c1023
Target Context                unconfined_u:object_r:user_home_dir_t:s0
Target Objects                /home/dummy [ dir ]
Source                        newaliases
Source Path                   /usr/sbin/sendmail.sendmail
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           sendmail-8.14.4-19.fc15
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.13-4.fc15
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 2.6.38-0.rc2.git0.1.fc15.i686.PAE
                              #1 SMP Sat Jan 22 19:11:02 UTC 2011 i686 i686
Alert Count                   1
First Seen                    Thu 27 Jan 2011 04:03:40 PM MST
Last Seen                     Thu 27 Jan 2011 04:03:40 PM MST
Local ID                      f43bca5c-a6d5-4335-abf4-cce61893c56b

Raw Audit Messages
type=AVC msg=audit(1296169420.833:86): avc:  denied  { read } for  pid=2818 comm="newaliases" path="/home/dummy" dev=dm-0 ino=125684 scontext=unconfined_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir


type=AVC msg=audit(1296169420.833:86): avc:  denied  { read } for  pid=2818 comm="newaliases" path="/home/dummy" dev=dm-0 ino=125684 scontext=unconfined_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir


type=SYSCALL msg=audit(1296169420.833:86): arch=i386 syscall=execve success=yes exit=0 a0=942cd68 a1=942ce00 a2=942b8a8 a3=942ce00 items=0 ppid=2817 pid=2818 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=486 sgid=486 fsgid=486 tty=pts0 ses=1 comm=newaliases exe=/usr/sbin/sendmail.sendmail subj=unconfined_u:system_r:system_mail_t:s0-s0:c0.c1023 key=(null)

Hash: newaliases,system_mail_t,user_home_dir_t,dir,read

audit2allow

#============= system_mail_t ==============
allow system_mail_t user_home_dir_t:dir read;

audit2allow -R

#============= system_mail_t ==============
allow system_mail_t user_home_dir_t:dir read;

--- Additional comment from Miroslav Grepl on 2011-01-31 04:25:28 EST ---

Looks like something what we want to dontaudit.

How did you get this?

--- Additional comment from Eric Blake on 2011-01-31 12:52:27 EST ---

(In reply to comment #1)
> Looks like something what we want to dontaudit.
> 
> How did you get this?

I first noticed it after incrementally upgrading to the latest rawhide; although I'm not sure if I could reliably reproduce it.  If it helps, I now have:
sendmail-8.14.4-19.fc15.i686
installed on 2011-01-15; the previous version was 8.14.4-17.fc15.i686.

--- Additional comment from Daniel Walsh on 2011-02-01 17:15:42 EST ---

Any reason sendmail would be listing the contents of /home/dummy?

--- Additional comment from Martin Holec on 2012-10-25 10:27:12 EDT ---

Reproducible on F18 with:
selinux-policy-3.11.1-43.fc18.noarch
sendmail-8.14.5-15.fc18.x86_64

(In reply to comment #3)
> Any reason sendmail would be listing the contents of /home/dummy?

Same question, moving to sendmail developers.

--- Additional comment from Jaroslav Škarvada on 2012-10-25 10:45:57 EDT ---

Hmm, strange. I cannot reproduce, nor find it in the code. Wouldn't be possible, there is such include in your aliases?

--- Additional comment from Eric Blake on 2012-10-25 19:04:34 EDT ---

I have not reproduced this issue in ages - perhaps Martin can give more details since he has a more recent experience with the message.

--- Additional comment from Nicolas Mailhot on 2012-12-03 13:00:57 EST ---

Is it a bug or a policy problem?

Package: (null)
Architecture: x86_64
OS Release: Fedora release 19 (Rawhide)

--- Additional comment from Jaroslav Škarvada on 2012-12-03 13:09:41 EST ---

(In reply to comment #7)
> Is it a bug or a policy problem?
> 
> Package: (null)
> Architecture: x86_64
> OS Release: Fedora release 19 (Rawhide)

Do you have reproducer?

Otherwise I am going to close this. It maybe caused by custom aliases.

--- Additional comment from Nicolas Mailhot on 2012-12-03 14:53:16 EST ---

drat, I don't know why sealert decided to duplicate this, my avc is

type=SYSCALL msg=audit(1354556349.393:17052): arch=c000003e syscall=59 success=yes exit=0 a0=9f9a90 a1=9f8f00 a2=9f7e50 a3=0 items=0 ppid=9247 pid=9248 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=2 tty=pts0 comm="newaliases" exe="/usr/sbin/sendmail.postfix" subj=unconfined_u:system_r:system_mail_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1354556349.393:17052): avc:  denied  { read } for  pid=9248 comm="newaliases" path="/home/nim" dev="dm-1" ino=12 scontext=unconfined_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir
type=AVC msg=audit(1354556349.393:17052): avc:  denied  { read } for  pid=9248 comm="newaliases" path="/home/nim" dev="dm-1" ino=12 scontext=unconfined_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir

so obviously a postfix not sendmail avc

--- Additional comment from Nicolas Mailhot on 2012-12-03 14:55:38 EST ---

(occurred just after a yum update, but the only mail-related thing in the yum transaction was a dovecot upgrade)

--- Additional comment from Jaroslav Škarvada on 2012-12-03 16:14:38 EST ---

Could you provide output of:
# postconf alias_database
And content of the file from its output? (e.g. /etc/aliases)

Are you able to reproduce by running:
# newaliases
?

--- Additional comment from Jaroslav Škarvada on 2012-12-04 11:12:35 EST ---

I retried on my systems but I wasn't able to reproduce.

--- Additional comment from Daniel Walsh on 2012-12-06 16:08:39 EST ---

ime->Thu Dec  6 06:29:29 2012
type=PATH msg=audit(1354793369.935:5376): item=1 name=(null) inode=1843751 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0
type=PATH msg=audit(1354793369.935:5376): item=0 name="/usr/bin/newaliases" inode=1851334 dev=fd:00 mode=0102755 ouid=0 ogid=51 rdev=00:00 obj=system_u:object_r:sendmail_exec_t:s0
type=CWD msg=audit(1354793369.935:5376):  cwd="/"
type=EXECVE msg=audit(1354793369.935:5376): argc=1 a0="/usr/bin/newaliases"
type=SYSCALL msg=audit(1354793369.935:5376): arch=c000003e syscall=59 success=yes exit=0 a0=2698590 a1=2697ae0 a2=2697050 a3=7fff83572040 items=2 ppid=4272 pid=4273 auid=3267 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 ses=3 tty=pts0 comm="newaliases" exe="/usr/sbin/sendmail.sendmail" subj=staff_u:system_r:system_mail_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1354793369.935:5376): avc:  denied  { read } for  pid=4273 comm="newaliases" path="/home/dwalsh" dev="dm-2" ino=131073 scontext=staff_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:user_home_dir_t:s0 tclass=dir


I got this on my F18 box.

--- Additional comment from Daniel Walsh on 2012-12-06 16:15:27 EST ---

Both of these are leaks.  Where a process has a open read descriptor on the homedir.

--- Additional comment from Daniel Walsh on 2012-12-06 16:17:26 EST ---

Fixed in selinux-policy-3.11.1-61.fc18.noarch


Added dontaudit.

--- Additional comment from Jaroslav Škarvada on 2012-12-06 16:39:13 EST ---

(In reply to comment #14)
> Both of these are leaks.  Where a process has a open read descriptor on the
> homedir.

Thanks for the info and workaround in the policy. I will dig into this in my spare time. Is there any reproducer? Just running newaliases? I wasn't able to reproduce.

--- Additional comment from Daniel Walsh on 2012-12-06 17:09:17 EST ---

No I believe this is caused by newalias being run either by the system or as part of a yum transaction.

--- Additional comment from Martin Holec on 2013-01-24 10:01:36 EST ---

Upgrade from clean installed F18 to F19 Rawhide.

Package: (null)
Architecture: x86_64
OS Release: Fedora release 19 (Rawhide)

--- Additional comment from Dan Mashal on 2013-03-07 23:24:18 EST ---

Description of problem:
yum update on rawhide

Additional info:
hashmarkername: setroubleshoot
kernel:         3.9.0-0.rc0.git14.1.fc19.x86_64
type:           libreport

--- Additional comment from Dan Mashal on 2013-03-07 23:27:02 EST ---

This is where this happens:

Updating   : setup-2.8.66-1.fc19.noarch                                57/422 
warning: /etc/shadow created as /etc/shadow.rpmnew

I see there is a new selinux policy. I will try again with it.