Bug 1014825 - SELinux is preventing systemd-readahe from 'read' accesses on the chr_file urandom.
SELinux is preventing systemd-readahe from 'read' accesses on the chr_file ur...
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
Depends On:
Blocks: F20FinalBlocker
  Show dependency treegraph
Reported: 2013-10-02 16:59 EDT by Adam Williamson
Modified: 2015-02-19 06:06 EST (History)
20 users (show)

See Also:
Fixed In Version: selinux-policy-3.12.1-90.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-11-10 01:21:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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-02 16:59:19 EDT
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.
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.
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 11:16:37 EDT
aa94525b8312b39a7c78da0e8bf00ff893762a46 fixes this in git.
Comment 2 cedjo7 2013-10-05 23:48:21 EDT
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 04:07:03 EDT
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 02:55:26 EDT
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 02:59:47 EDT
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. "

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-13 23:10:42 EDT
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 12:30:24 EDT
selinux-policy-3.12.1-90.fc20 has been submitted as an update for Fedora 20.
Comment 9 Fedora Update System 2013-10-17 16:21:47 EDT
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:
then log in and leave karma (feedback).
Comment 10 satellitgo 2013-10-25 13:23:33 EDT
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 13:45:42 EDT
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 19:48:33 EDT
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 01:21:32 EST
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.

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