Bug 1021730 - SELinux is preventing systemd-logind from 'open' accesses on the chr_file /dev/urandom.
SELinux is preventing systemd-logind from 'open' accesses on the chr_file /de...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
20
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
abrt_hash:a15c1b294c4a23181e081f75192...
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-21 19:19 EDT by Adam Williamson
Modified: 2014-08-22 08:44 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-08-22 08:44:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adam Williamson 2013-10-21 19:19:25 EDT
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 03:41:50 EDT
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 12:24:16 EDT
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 12:25:14 EDT
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 13:21:30 EDT
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 17:10:18 EDT
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

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