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.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Description of problem: The alert showed up when installing today's updates. I think it was during "setup" package installation. Additional info: hashmarkername: setroubleshoot kernel: 3.9.0-0.rc6.git2.3.fc19.x86_64 type: libreport
Description of problem: Came up during an update. Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.1-301.fc19.x86_64 type: libreport
Description of problem: I really don't know what happened here. This is my new laptop, so a fairly clean F19, and I just opened it up and ran a 'yum update', then noticed this AVC. I haven't explicitly configured sendmail at all, it's just got the default configuration. No idea why it wants to read my homedir. Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.1-301.fc19.x86_64 type: libreport
Description of problem: Didn't do anything special. Sendmail seems to have been doing it's own thing in the background. Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.1-301.fc19.x86_64 type: libreport
Probably we should open also a bug for sendmail to ask what it does.
Well these are not sendmail or sendmail.postfix bugs, they are leakes from the application that is executing sendmail or sendmail.postfix. Some application running in the postinstall is sending email while is has a open read file descriptor to /home/dummy. or /home/nim If we could figure out which app is calling newalias, then we would know who is leaking. Simplest fix would be to add a dontaudit for this.
dan: it's not immediate post-install, or anything (for me anyway) - the laptop's fairly new, but it's been installed for a while. I was just doing 'normal stuff' on it when this hit. But yeah, I've no idea what's calling sendmail :| I suppose I can look through /var/spool/mail and see what's there...
Created attachment 749536 [details] journalctl -b For me this happened during a yum update from 19 beta RC2 after rebooting from installing. Lots of messages in audit.log and journalctl. The time of the denial is 20:42:23. May 17 20:42:23 localhost.localdomain dbus-daemon[356]: dbus[356]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper) May 17 20:42:23 localhost.localdomain dbus[356]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper) May 17 20:42:23 localhost.localdomain sendmail[2245]: alias database /etc/aliases rebuilt by chris May 17 20:42:23 localhost.localdomain sendmail[2245]: /etc/aliases: 76 aliases, longest 10 bytes, 771 bytes total Prior to that, just a bunch of yum entries.
Created attachment 749537 [details] audit.log
Well we already had dontaudit for search, now we can add listing. -userdom_dontaudit_search_user_home_dirs(system_mail_t) +userdom_dontaudit_list_user_home_dirs(system_mail_t) userdom_dontaudit_list_admin_dir(system_mail_t) 91de1dc704ee69922424e1e4aac5c72d1025b579 Fixes this in git.
Added also to F18.
Description of problem: Happened during system update. Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.0-0.rc8.git0.2.fc19.x86_64 type: libreport
*** Bug 919802 has been marked as a duplicate of this bug. ***
Description of problem: Updating F19 from stable repository. May be yum wanted send me mail. Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.2-301.fc19.x86_64 type: libreport
Description of problem: Fresh install of Beta. Just updating. Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.2-301.fc19.x86_64 type: libreport
It seems setup package is calling newaliases in its %post, but I was not successful in finding the FD leak, nor I was unable to reproduce this. I will continue to investigate. Is there wso2-wsf-cpp package installed on the affected systems?
Description of problem: This pop-up during system update. Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.2-301.fc19.x86_64 type: libreport
Description of problem: during updates Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.2-301.fc19.i686 type: libreport
*** Bug 970346 has been marked as a duplicate of this bug. ***
Created attachment 833223 [details] Use CLO_EXEC I dug more deep into it. It seems the problem is triggered by the setup package. It executes newaliases from the LUA code in its %post. This way the FD opened earlier in the transaction can leak into newaliases. Newaliases are provided by both sendmail and postfix, that's why the same problem was reported twice against different packages. The problem is very hardly reproducible. I was able to reproduce it with both yum and dnf, but it doesn't seem to be 100% repeatedly reproducible (I wasn't able to reproduce it repeatedly even by replying the same transaction in the snapshoted VM). I think RPM should use CLO_EXEC on FDs it opens. Attached patch tries to fix it. It was created by blind (automatic) find and replace, so it needs careful review. By using the patched RPM, I wasn't able to reproduce the problem again (this may also mean that I wasn't just lucky enough to trigger the probem).
Right, another embedded Lua "specialty"... For regular scriptlets rpm forces FD_CLOEXEC after fork, but this doesn't occur with the embedded Lua scriptlets. So yeah, there is a problem which needs addressing. The patch looks a bit like a blind man trying to kill a fly on a wall with an extremely large hammer though :)
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
Fixed upstream by setting FD_CLOEXEC on opened files before exec from lua script is called: https://github.com/rpm-software-management/rpm/commit/7a7c31f551ff167f8718aea6d5048f6288d60205
Unfortunately this fix can cause a serious performance regression, for example in Docker, where ulimit -n is a lot higher: https://bugzilla.redhat.com/show_bug.cgi?id=1537564