Bug 1014825

Summary: SELinux is preventing systemd-readahe from 'read' accesses on the chr_file urandom.
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: bondhu.paul, brianlamere, bugzilla, cedjo7, dominick.grift, dwalsh, fran, frankly3d, kparal, kuc4iman, lvrabec, marco.kunzli, mbriza, mgrepl, mikhail.v.gavrilov, nonamedotc, pierluigi.fiorini, robatino, satellitgo, sergei.ksmith
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:33c3d515c9a0e3a66314e80eb21f2baf2f54a5ad6dbab9fbc7dd848508fbdff2
Fixed In Version: selinux-policy-3.12.1-90.fc20 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-10 06:21:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 980656    

Description Adam Williamson 2013-10-02 20:59:19 UTC
Description of problem:
Happens during boot up. systemd-readahead shouldn't be trying to do something SELinux disallows by default.
SELinux is preventing systemd-readahe from 'read' accesses on the chr_file urandom.

*****  Plugin catchall_boolean (89.3 confidence) suggests   ******************

If you want to enable reading of urandom for all domains.
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 (11.6 confidence) suggests   **************************

If you believe that systemd-readahe should be allowed read 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-readahe /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:readahead_t:s0
Target Context                system_u:object_r:urandom_device_t:s0
Target Objects                urandom [ chr_file ]
Source                        systemd-readahe
Source Path                   systemd-readahe
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.12.1-84.fc20.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 3.12.0-0.rc3.git1.2.fc21.x86_64 #1
                              SMP Wed Oct 2 02:25:48 UTC 2013 x86_64 x86_64
Alert Count                   8
First Seen                    2013-10-02 21:24:36 BST
Last Seen                     2013-10-02 21:44:46 BST
Local ID                      e1012ee4-bfd0-4446-90e1-dd98dd7ebc97

Raw Audit Messages
type=AVC msg=audit(1380746686.208:33): avc:  denied  { read } for  pid=554 comm="systemd-readahe" name="urandom" dev="devtmpfs" ino=1033 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file


Hash: systemd-readahe,readahead_t,urandom_device_t,chr_file,read

Additional info:
reporter:       libreport-2.1.7
hashmarkername: setroubleshoot
kernel:         3.12.0-0.rc3.git1.2.fc21.x86_64
type:           libreport

Comment 1 Daniel Walsh 2013-10-04 15:16:37 UTC
aa94525b8312b39a7c78da0e8bf00ff893762a46 fixes this in git.

Comment 2 cedjo7 2013-10-06 03:48:21 UTC
Description of problem:
this happen when the session starts after login, not sure if this should be allowed or not

Additional info:
reporter:       libreport-2.1.7
hashmarkername: setroubleshoot
kernel:         3.11.3-301.fc20.x86_64
type:           libreport

Comment 3 Frank Murphy 2013-10-06 08:07:03 UTC
Description of problem:
I use a usb stick with "secreykey" for unlocking luks partitions.
It works, but this avc is new (yesterday and today)
I am uncerain if the setebool is required what has changed?
USB still unlocks the partitions.
Aside from that, no  ideas.

Additional info:
reporter:       libreport-2.1.7
hashmarkername: setroubleshoot
kernel:         3.12.0-0.rc3.git4.2.fc20.x86_64
type:           libreport

Comment 5 Kamil Páral 2013-10-10 06:55:26 UTC
Description of problem:
I see this on default boot of F20 Beta TC2 Live x86_64 converted to USB using dd. The warning doesn't pop up, but it can be seen after opening SELinux troubleshooter.

Additional info:
reporter:       libreport-2.1.7
hashmarkername: setroubleshoot
kernel:         3.11.3-301.fc20.x86_64
type:           libreport

Comment 6 Kamil Páral 2013-10-10 06:59:47 UTC
Proposing as a blocker:
"There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop. "
https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#SELinux_and_crash_notifications

Please note that there is no actual notification (there might be a bug that prevents notifications from popping up?). But the error is there.

Comment 7 Brian LaMere 2013-10-14 03:10:42 UTC
Description of problem:
happens every time during boot; when I log in, I get a selinux alert

I am using rpmfusion repos now, but it was already happening prior to that.  Installed as a basic with Mate, then added items.

Additional info:
reporter:       libreport-2.1.8
hashmarkername: setroubleshoot
kernel:         3.11.4-301.fc20.x86_64
type:           libreport

Comment 8 Fedora Update System 2013-10-15 16:30:24 UTC
selinux-policy-3.12.1-90.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-90.fc20

Comment 9 Fedora Update System 2013-10-17 20:21:47 UTC
Package selinux-policy-3.12.1-90.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-90.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-19129/selinux-policy-3.12.1-90.fc20
then log in and leave karma (feedback).

Comment 10 satellitgo 2013-10-25 17:23:33 UTC
see this in liveusb-creator USB with persistence file of F20 Beta TC-5 Desktop.
Initial boot works. Cnges are stored in persitence file.
on reboot of USB  fails at initial screen but on 2nd boot it finds file and runs. 3rd reboot fails, 4th boot works? ABRT message is identical

Comment 11 Adam Williamson 2013-10-25 17:45:42 UTC
I see the systemd-readahea messages in almost all F20 systems at present, but I'm not sure it's what is actually breaking your live persistence case. I think it's a fairly 'harmless' error - readahead is really just a mechanism to try and make boot a bit faster, I think, so worst case if it breaks is just that boot runs a bit slower. But I might be missing something. You could try using enforcing=0 or selinux=0 with your persistence tests and see if it changes anything.

Comment 12 satellitgo 2013-10-25 23:48:33 UTC
Description of problem:
part of testing Desktop login created 2nd user and tried to log out/in to it: 
"gnome-keyring-daemon not responding"
Could not do shutdown so did shutdown -h now from second user
On reboot logged in to user2  and got this error.
Keyring asked for password for second user to allow reporting

Additional info:
reporter:       libreport-2.1.8
hashmarkername: setroubleshoot
kernel:         3.11.5-302.fc20.x86_64
type:           libreport

Comment 13 Fedora Update System 2013-11-10 06:21:32 UTC
selinux-policy-3.12.1-90.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.