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;
Looks like something what we want to dontaudit. How did you get this?
(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.
Any reason sendmail would be listing the contents of /home/dummy?
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.
Hmm, strange. I cannot reproduce, nor find it in the code. Wouldn't be possible, there is such include in your aliases?
I have not reproduced this issue in ages - perhaps Martin can give more details since he has a more recent experience with the message.
Is it a bug or a policy problem? Package: (null) Architecture: x86_64 OS Release: Fedora release 19 (Rawhide)
(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.
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
(occurred just after a yum update, but the only mail-related thing in the yum transaction was a dovecot upgrade)
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 ?
I retried on my systems but I wasn't able to reproduce.
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.
Both of these are leaks. Where a process has a open read descriptor on the homedir.
Fixed in selinux-policy-3.11.1-61.fc18.noarch Added dontaudit.
(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.
No I believe this is caused by newalias being run either by the system or as part of a yum transaction.
Upgrade from clean installed F18 to F19 Rawhide. Package: (null) Architecture: x86_64 OS Release: Fedora release 19 (Rawhide)
Description of problem: yum update on rawhide Additional info: hashmarkername: setroubleshoot kernel: 3.9.0-0.rc0.git14.1.fc19.x86_64 type: libreport
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.
Seems to work OK now. Will re-open if needed.
*** Bug 928978 has been marked as a duplicate of this bug. ***