Bug 1021730

Summary: SELinux is preventing systemd-logind from 'open' accesses on the chr_file /dev/urandom.
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: dominick.grift, dwalsh, luya, lvrabec, mgrepl
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:a15c1b294c4a23181e081f751928e05c36c9e00fce8eca402cf35ed50d7b7f80
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-08-22 12:44:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Adam Williamson 2013-10-21 23:19:25 UTC
Description of problem:
On startup or running of Firefox from a test day live image I'm building for F20 graphics test week.
SELinux is preventing systemd-logind from 'open' accesses on the chr_file /dev/urandom.

*****  Plugin catchall_boolean (47.5 confidence) suggests   ******************

If you want to allow authlogin to nsswitch use ldap
Then you must tell SELinux about this by enabling the 'authlogin_nsswitch_use_ldap' boolean.
You can read 'None' man page for more details.
Do
setsebool -P authlogin_nsswitch_use_ldap 1

*****  Plugin catchall_boolean (47.5 confidence) suggests   ******************

If you want to allow global to ssp
Then you must tell SELinux about this by enabling the 'global_ssp' boolean.
You can read 'None' man page for more details.
Do
setsebool -P global_ssp 1

*****  Plugin catchall (6.38 confidence) suggests   **************************

If you believe that systemd-logind should be allowed open access on the urandom chr_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 systemd-logind /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:systemd_logind_t:s0
Target Context                system_u:object_r:urandom_device_t:s0
Target Objects                /dev/urandom [ chr_file ]
Source                        systemd-logind
Source Path                   systemd-logind
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.12.1-75.fc20.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     (removed)
Platform                      Linux (removed) 3.11.6-300.fc20.x86_64 #1 SMP Fri
                              Oct 18 22:31:53 UTC 2013 x86_64 x86_64
Alert Count                   1
First Seen                    2013-10-21 19:16:10 EDT
Last Seen                     2013-10-21 19:16:10 EDT
Local ID                      59b6ba58-1d0a-4ce1-8013-9c97e518d662

Raw Audit Messages
type=AVC msg=audit(1382397370.370:454): avc:  denied  { open } for  pid=540 comm="systemd-logind" path="/dev/urandom" dev="devtmpfs" ino=5966 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file


Hash: systemd-logind,systemd_logind_t,urandom_device_t,chr_file,open

Additional info:
reporter:       libreport-2.1.8
hashmarkername: setroubleshoot
kernel:         3.11.6-300.fc20.x86_64
type:           libreport

Comment 1 Lukas Vrabec 2013-10-22 07:41:50 UTC
Hi, 
Please update your system, to fix it. 

$ audit2allow -i avc 


#============= systemd_logind_t ==============

#!!!! This avc is allowed in the current policy
allow systemd_logind_t urandom_device_t:chr_file open;

$ rpm -q selinux-policy
selinux-policy-3.12.1-90.fc20.noarch

Comment 2 Adam Williamson 2013-10-22 16:24:16 UTC
No. The point of my report is that this kind of alert shouldn't just pop up for a regular user doing regular user stuff. I wasn't doing anything unusual.

Comment 3 Adam Williamson 2013-10-22 16:25:14 UTC
you might want to say 'let's re-assign this to whoever's doing something I don't think they should be doing out of the box', for instance, but our default policy and typical actions by desktop components should really be aligned. Having said that, I'm not sure precisely what *did* trigger this :(

Comment 4 Daniel Walsh 2013-10-22 17:21:30 UTC
Well the old version of policy was causing it.  Other then turning off sealert at the users session, and/or updating the policy, not sure how we fix this.

Comment 5 Luya Tshimbalanga 2013-10-25 21:10:18 UTC
Description of problem:
The problem happened after the creation of user in Gnome Shell while leaving the other user session active with running video. Test done on graphical testday Fedora 20.

Additional info:
reporter:       libreport-2.1.8
hashmarkername: setroubleshoot
kernel:         3.11.6-300.fc20.x86_64
type:           libreport