Bug 919801 - SELinux is preventing /usr/sbin/sendmail.postfix from 'read' accesses on the directory /home/dummy.
Summary: SELinux is preventing /usr/sbin/sendmail.postfix from 'read' accesses on the ...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 23
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: setroubleshoot_trace_hash:e1d2259087e...
: 919802 970346 (view as bug list)
Depends On: 673384
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-10 07:44 UTC by Nicolas Mailhot
Modified: 2018-03-10 20:34 UTC (History)
42 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 673384
Environment:
Last Closed: 2016-05-31 08:35:31 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
journalctl -b (322.54 KB, text/plain)
2013-05-18 03:13 UTC, Chris Murphy
no flags Details
audit.log (178.19 KB, text/plain)
2013-05-18 03:14 UTC, Chris Murphy
no flags Details
Use CLO_EXEC (23.83 KB, patch)
2013-12-05 15:47 UTC, Jaroslav Škarvada
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1537564 0 unspecified CLOSED Iterating over _SC_OPEN_MAX descriptors in doScriptExec() is causing serious performance regression when _SC_OPEN_MAX is... 2021-02-22 00:41:40 UTC

Description Nicolas Mailhot 2013-03-10 07:44:24 UTC
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.

Comment 1 Fedora End Of Life 2013-04-03 18:16:38 UTC
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

Comment 2 Dawid Zamirski 2013-04-18 21:16:51 UTC
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

Comment 3 Ankur Sinha (FranciscoD) 2013-05-15 02:39:12 UTC
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

Comment 4 Adam Williamson 2013-05-15 20:40:24 UTC
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

Comment 5 Kjartan Maraas 2013-05-16 08:00:35 UTC
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

Comment 6 Miroslav Grepl 2013-05-16 10:28:13 UTC
Probably we should open also a bug for sendmail to ask what it does.

Comment 7 Daniel Walsh 2013-05-17 12:40:50 UTC
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.

Comment 8 Adam Williamson 2013-05-17 16:16:30 UTC
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...

Comment 9 Chris Murphy 2013-05-18 03:13:52 UTC
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.

Comment 10 Chris Murphy 2013-05-18 03:14:42 UTC
Created attachment 749537 [details]
audit.log

Comment 11 Daniel Walsh 2013-05-18 10:07:16 UTC
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.

Comment 12 Miroslav Grepl 2013-05-20 09:34:57 UTC
Added also to F18.

Comment 13 Kamil Páral 2013-05-20 14:00:04 UTC
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

Comment 14 Jaroslav Škarvada 2013-05-24 12:28:55 UTC
*** Bug 919802 has been marked as a duplicate of this bug. ***

Comment 15 Igor Gnatenko 2013-05-25 18:36:19 UTC
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

Comment 16 Ankur Sinha (FranciscoD) 2013-05-28 15:03:53 UTC
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

Comment 17 Jaroslav Škarvada 2013-05-29 12:27:16 UTC
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?

Comment 18 Vít Ondruch 2013-05-31 13:06:51 UTC
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

Comment 19 gil cattaneo 2013-07-03 16:32:52 UTC
Description of problem:
during updates

Additional info:
reporter:       libreport-2.1.4
hashmarkername: setroubleshoot
kernel:         3.9.2-301.fc19.i686
type:           libreport

Comment 20 Jaroslav Škarvada 2013-12-05 14:46:34 UTC
*** Bug 970346 has been marked as a duplicate of this bug. ***

Comment 21 Jaroslav Škarvada 2013-12-05 15:47:59 UTC
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).

Comment 22 Panu Matilainen 2013-12-09 09:31:36 UTC
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 :)

Comment 23 Jan Kurik 2015-07-15 14:50:07 UTC
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

Comment 24 Ľuboš Kardoš 2016-05-31 08:35:31 UTC
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

Comment 25 Alex Kanavin 2018-01-23 14:05:15 UTC
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


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