Bug 864143 (systemd_fifo)

Summary: SELinux is preventing /usr/sbin/httpd from 'write' accesses on the fifo_file /run/systemd/sessions/110.ref (deleted).
Product: [Fedora] Fedora Reporter: Nicolas Mailhot <nicolas.mailhot>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 23CC: alessandro.bruni, dcharlespyle, decathorpe, dominick.grift, dwalsh, fidelleon, flokip, i, ignatenko, jjelen, johannbg, jsmith.fedora, lnykryn, luya, lvrabec, mgrepl, moez.roy, msekleta, nonamedotc, plautrba, slukasik, suraia, systemd-maint, vpavlin, zbyszek
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:6d31f313ed2888ce336b02499f8216e49198ef1643c6d946eab7b1848c632bba
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-12-15 14:20:55 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
File: type
none
File: hashmarkername none

Description Nicolas Mailhot 2012-10-08 13:54:15 EDT
Additional info:
libreport version: 2.0.15
kernel:         3.7.0-0.rc0.git2.4.fc19.x86_64

description:
:SELinux is preventing /usr/sbin/httpd from 'write' accesses on the fifo_file /run/systemd/sessions/110.ref (deleted).
:
:*****  Plugin leaks (86.2 confidence) suggests  ******************************
:
:If vous souhaitez ignorer que httpd tente d'obtenir l'accès write à 110.ref (deleted) fifo_file car vous pensez qu'il ne devrait pas nécessiter cet accès.
:Then vous devriez rapporter ceci en tant qu'anomalie.  
:Vous pouvez générer un module de stratégie local pour dontaudit cet accès.
:Do
:# grep /usr/sbin/httpd /var/log/audit/audit.log | audit2allow -D -M mypol
:# semodule -i mypol.pp
:
:*****  Plugin catchall (14.7 confidence) suggests  ***************************
:
:If vous pensez que httpd devrait être autorisé à accéder write sur 110.ref (deleted) fifo_file par défaut.
:Then vous devriez rapporter ceci en tant qu'anomalie.
:Vous pouvez générer un module de stratégie local pour autoriser cet accès.
:Do
:autoriser cet accès pour le moment en exécutant :
:# grep httpd /var/log/audit/audit.log | audit2allow -M mypol
:# semodule -i mypol.pp
:
:Additional Information:
:Source Context                system_u:system_r:httpd_t:s0-s0:c0.c1023
:Target Context                system_u:object_r:systemd_logind_sessions_t:s0
:Target Objects                /run/systemd/sessions/110.ref (deleted) [
:                              fifo_file ]
:Source                        httpd
:Source Path                   /usr/sbin/httpd
:Port                          <Inconnu>
:Host                          (removed)
:Source RPM Packages           httpd-2.4.3-10.fc19.x86_64
:Target RPM Packages           
:Policy RPM                    selinux-policy-3.11.1-32.fc18.noarch
:Selinux Enabled               True
:Policy Type                   targeted
:Enforcing Mode                Enforcing
:Host Name                     (removed)
:Platform                      Linux (removed) 3.7.0-0.rc0.git2.4.fc19.x86_64 #1
:                              SMP Fri Oct 5 20:59:24 UTC 2012 x86_64 x86_64
:Alert Count                   1
:First Seen                    2012-10-08 03:22:02 CEST
:Last Seen                     2012-10-08 03:22:02 CEST
:Local ID                      5472903d-d88e-4169-8bef-891e60e16d91
:
:Raw Audit Messages
:type=AVC msg=audit(1349659322.445:8771): avc:  denied  { write } for  pid=7137 comm="httpd" path=2F72756E2F73797374656D642F73657373696F6E732F3131302E726566202864656C6574656429 dev="tmpfs" ino=2143403 scontext=system_u:system_r:httpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_logind_sessions_t:s0 tclass=fifo_file
:
:
:type=SYSCALL msg=audit(1349659322.445:8771): arch=x86_64 syscall=execve success=yes exit=0 a0=20f3170 a1=20f3370 a2=20fabf0 a3=3 items=0 ppid=7136 pid=7137 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=110 tty=(none) comm=httpd exe=/usr/sbin/httpd subj=system_u:system_r:httpd_t:s0-s0:c0.c1023 key=(null)
:
:Hash: httpd,httpd_t,systemd_logind_sessions_t,fifo_file,write
:
:audit2allow
:
:#============= httpd_t ==============
:allow httpd_t systemd_logind_sessions_t:fifo_file write;
:
:audit2allow -R
:
:#============= httpd_t ==============
:allow httpd_t systemd_logind_sessions_t:fifo_file write;
:
Comment 1 Nicolas Mailhot 2012-10-08 13:54:18 EDT
Created attachment 623600 [details]
File: type
Comment 2 Nicolas Mailhot 2012-10-08 13:54:20 EDT
Created attachment 623601 [details]
File: hashmarkername
Comment 3 Miroslav Grepl 2012-10-09 04:18:26 EDT
*** Bug 864144 has been marked as a duplicate of this bug. ***
Comment 4 Miroslav Grepl 2012-10-09 04:18:34 EDT
*** Bug 864145 has been marked as a duplicate of this bug. ***
Comment 5 Miroslav Grepl 2012-10-09 04:18:42 EDT
*** Bug 864146 has been marked as a duplicate of this bug. ***
Comment 6 Miroslav Grepl 2012-10-09 04:18:49 EDT
*** Bug 864147 has been marked as a duplicate of this bug. ***
Comment 7 Miroslav Grepl 2012-10-09 04:18:58 EDT
*** Bug 864148 has been marked as a duplicate of this bug. ***
Comment 8 Miroslav Grepl 2012-10-09 04:19:07 EDT
*** Bug 864149 has been marked as a duplicate of this bug. ***
Comment 9 Miroslav Grepl 2012-10-09 04:19:15 EDT
*** Bug 864151 has been marked as a duplicate of this bug. ***
Comment 10 Miroslav Grepl 2012-10-09 04:19:22 EDT
*** Bug 864152 has been marked as a duplicate of this bug. ***
Comment 11 Miroslav Grepl 2012-10-09 04:19:30 EDT
*** Bug 864153 has been marked as a duplicate of this bug. ***
Comment 12 Daniel Walsh 2012-10-09 11:55:05 EDT
Could this be a leak in systemd?
Comment 13 Lennart Poettering 2012-10-12 17:41:23 EDT
(In reply to comment #12)
> Could this be a leak in systemd?

Only if for PAM got loaded into apache in some way and went through a session registration. 

Nicolas, did you use any special Apache configuration?
Comment 14 Nicolas Mailhot 2012-10-13 02:56:32 EDT
The only 'special' configuration is deployment of apache + squirelmail + dovecot (all from fedora rpms)
Comment 15 Daniel Walsh 2012-10-16 09:39:05 EDT
Does squirrelmail do authorization using the pam stack?
Comment 16 Nicolas Mailhot 2012-10-16 11:27:38 EDT
(In reply to comment #15)
> Does squirrelmail do authorization using the pam stack?

it's supposed to talk to an imap server, that does its own authorisation

But anyway there is no need to focus on apache since most of the dupes are for other system apps
Comment 17 Daniel Walsh 2012-10-16 12:11:25 EDT
Ok now that I look at this again, it looks like a leak,
Comment 18 Daniel Walsh 2012-10-16 12:12:56 EDT
Some tool is opening up this socket and then updating the packages, which is causing the leak.  I would figure this is happening during a yum/rpm transaction.
Comment 19 D. Charles Pyle 2014-02-27 05:35:32 EST
I got this same error, but in that case it was systemd trying to rotate log files.  SElinux stopped it from being able to rotate those logs.  Isn't systemd supposed to have fifo access to files and to be able to rotate logs? In my case, there was no yum transaction going on.  I was just reading a book on the Internet over at Amazon.com.  This error was immediately followed by three more involving /bin/bash.  Again, I was doing nothing but reading an e-Text. A quick check using system monitor to view all processes showed that neither yum nor PackageKit were running at the time of the errors.
Comment 20 Daniel Walsh 2014-02-27 09:10:14 EST
Are you sure you are seeing the same AVC?  Please attach what you are getting.
Comment 21 D. Charles Pyle 2014-02-27 09:19:26 EST
Crap!  I wish you had asked me that yesterday. :-)

Unfortunately, I deleted everything from the SELinux troubleshooter after updating selinux-policy early this morning. (I was watching the build on Koji and updated as soon as building was complete).  If I see this again, I'll send it up.

However, the SELinux Troubleshooter itself referred me here initially.
Comment 22 Michael Kuhn 2014-02-28 10:36:14 EST
The same happens to me since upgrading to systemd 210 whenever cronjobs run.

In my case, this happens during cron.daily for logrotate, bash (man-db, I guess) and updatedb.

SELinux is preventing /usr/bin/updatedb from write access on the fifo_file /run/systemd/sessions/2.ref (deleted).
                                   
*****  Plugin leaks (86.2 confidence) suggests   *****************************

If you want to ignore updatedb trying to write access the 2.ref (deleted) fifo_file, 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/bin/updatedb /var/log/audit/audit.log | audit2allow -D -M mypol
# semodule -i mypol.pp

*****  Plugin catchall (14.7 confidence) suggests   **************************

If you believe that updatedb should be allowed write access on the 2.ref (deleted) fifo_file 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 updatedb /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Comment 23 Daniel Walsh 2014-02-28 17:22:08 EST
This issue is a systemd issue  Lots of domains are seeing it.
Comment 24 Christopher Meng 2014-03-03 19:55:15 EST
I think it's not a selinux problem, because yesterday I only updated systemd!
Comment 25 Igor Gnatenko 2014-03-04 00:53:56 EST
SELinux is preventing /usr/sbin/logrotate from write access on the fifo_file .

*****  Plugin leaks (86.2 confidence) suggests   *****************************

If you want to ignore logrotate trying to write access the  fifo_file, 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/logrotate /var/log/audit/audit.log | audit2allow -D -M mypol
# semodule -i mypol.pp

*****  Plugin catchall (14.7 confidence) suggests   **************************

If you believe that logrotate should be allowed write access on the  fifo_file 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 logrotate /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:logrotate_t:s0-s0:c0.c1023
Target Context                system_u:object_r:systemd_logind_sessions_t:s0
Target Objects                 [ fifo_file ]
Source                        logrotate
Source Path                   /usr/sbin/logrotate
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           logrotate-3.8.7-1.fc21.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-28.fc21.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux X1Carbon.localdomain
                              3.14.0-0.rc4.git3.1.fc21.x86_64 #1 SMP Sat Mar 1
                              12:20:41 UTC 2014 x86_64 x86_64
Alert Count                   3
First Seen                    2014-03-02 03:38:02 MSK
Last Seen                     2014-03-04 09:47:01 MSK
Local ID                      d0b08ee1-eca5-4373-b90f-4f728e1ec91f

Raw Audit Messages
type=AVC msg=audit(1393912021.693:483): avc:  denied  { write } for  pid=5071 comm="logrotate" path=2F72756E2F73797374656D642F73657373696F6E732F322E726566202864656C6574656429 dev="tmpfs" ino=33714 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_logind_sessions_t:s0 tclass=fifo_file


type=SYSCALL msg=audit(1393912021.693:483): arch=x86_64 syscall=execve success=yes exit=0 a0=21fe5e0 a1=21fd5e0 a2=21fcf80 a3=8 items=0 ppid=5069 pid=5071 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm=logrotate exe=/usr/sbin/logrotate subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)

Hash: logrotate,logrotate_t,systemd_logind_sessions_t,fifo_file,write
Comment 26 Luya Tshimbalanga 2014-03-12 15:21:44 EDT
Description of problem:
Testing rawhide from Gnome Boxes.

Additional info:
reporter:       libreport-2.2.0
hashmarkername: setroubleshoot
kernel:         3.14.0-0.rc6.git0.1.fc21.x86_64
type:           libreport
Comment 27 Luya Tshimbalanga 2014-04-04 19:53:02 EDT
Description of problem:
Logged in 

Additional info:
reporter:       libreport-2.2.0
hashmarkername: setroubleshoot
kernel:         3.14.0-1.fc21.x86_64
type:           libreport
Comment 28 Luya Tshimbalanga 2014-04-17 15:40:34 EDT
Description of problem:
opening a terminal and running an update

Version-Release number of selected component:
selinux-policy-3.13.1-45.fc21.noarch

Additional info:
reporter:       libreport-2.2.1
hashmarkername: setroubleshoot
kernel:         3.15.0-0.rc1.git1.1.fc21.x86_64
type:           libreport
Comment 29 Daniel Walsh 2014-04-23 21:27:27 EDT
Just checked in a dontaudit for this access.
9d4e76afdae04cb79e8b0e2222051b60e7d6b021  Since it does not seem to be being fixed.
Comment 30 Daniel Walsh 2014-04-23 21:31:30 EDT
*** Bug 1070268 has been marked as a duplicate of this bug. ***
Comment 31 Jakub Jelen 2014-04-29 11:46:05 EDT
I fixed similar issue in cron - my bugzilla: 1075106.

I don't think, that this should be fixed only with dontaudit rule.
Comment 32 Lennart Poettering 2014-06-19 18:53:16 EDT
*** Bug 1074307 has been marked as a duplicate of this bug. ***
Comment 33 Zbigniew Jędrzejewski-Szmek 2015-05-10 16:38:48 EDT
(In reply to Daniel Walsh from comment #29)
> Just checked in a dontaudit for this access.
> 9d4e76afdae04cb79e8b0e2222051b60e7d6b021  Since it does not seem to be being
> fixed.

I think this should be fixed by http://cgit.freedesktop.org/systemd/systemd/commit/?id=85c08dc013. It was v212-348-g85c08dc013 upstream, and has landed in F21/F22/F23 a while ago.

Can you revert the dontaudit rule?
Comment 34 Jan Kurik 2015-07-15 10:58:28 EDT
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