Description of problem: When audio-entropyd is started by systemd, SELinux generates the following error message. SELinux is preventing /usr/sbin/audio-entropyd from read access on the file /usr/share/alsa/alsa.conf. ***** Plugin catchall_boolean (89.3 confidence) suggests ****************** If you want to determine whether entropyd can use audio devices as the source for the entropy feeds. Then you must tell SELinux about this by enabling the 'entropyd_use_audio' boolean. You can read 'alsa_selinux' man page for more details. Do setsebool -P entropyd_use_audio 1 ***** Plugin catchall (11.6 confidence) suggests ************************** If you believe that audio-entropyd should be allowed read access on the alsa.conf 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 audio-entropyd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Version-Release number of selected component (if applicable): selinux-policy-targeted-3.12.1-122.fc20.noarch How reproducible: every time Steps to Reproduce: 1. Install audio-entropyd 2. Ensure it is enabled in systemd. (systemctl -a -t service) 3. Reboot the computer Actual results: Above error message Expected results: audio-entropyd forks into background and runs. Additional info: There is a bugzilla opened against audio-entropyd for this problem, but I don't think audio-entropyd is the problem. The program only accesses alsa through the standard API, and does no read on the file mentioned. It doesn't need the access that SELinux is denying. So, either SELinux has a bug for alsa access from the standard API, or systemd or dbus are accessing this file as if they are audio-entropyd, and failing. https://bugzilla.redhat.com/show_bug.cgi?id=982660 The program starts and runs fine if started by dwatch, via crond. I am, however, using a sound device dedicated to audio-entropyd, and turned off in pavucontrol, so pulseaudio is not managing it. i.e. alsa has control of the device I tried the second method mentioned in the SELinux error, but it didn't work. In addition, audio-entropyd doesn't *need* this access to run.
Not sure why this is not allowed by default. Seems we should just allow it and remove the boolean.
I think I agree with you. Mostly I was hoping someone would say, "Oh, that's the same as xxxxxxx. It's being worked on." Trying to track this down during startup would be difficult. But there is definitely some interaction here that is triggering SELinux for a program that shouldn't fail. Removing the boolean is sort of like saying, "That infection isn't so bad. We'll just pretend we never saw it." And in the grand scheme of Fedora and SELinux things, this is probably pretty low priority, so that makes sense. I don't see an easy way this will allow the system to be compromised, though I'm no expert. So, my vote is to remove it. Life's full of little compromises. :-)
commit c9afc6c119ed2006d99d36334f33f646f2052d44 Author: Miroslav Grepl <mgrepl> Date: Mon Mar 10 09:39:30 2014 +0100 Turn on entropyd_use_audio boolean by default
I guess that will work. I don't think there can be any security repercussions since the file is world readable. -rw-r--r--. 0 0 system_u:object_r:alsa_etc_rw_t:s0 /usr/share/alsa/alsa.conf
selinux-policy-3.12.1-135.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-135.fc20
Package selinux-policy-3.12.1-135.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-135.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-3813/selinux-policy-3.12.1-135.fc20 then log in and leave karma (feedback).
The fix works. Systemd is able to start audio-entropyd and it continues running. However, when I ran the update of selinux, I received the errors below. My system seems to be functioning OK, but seeing all those 'invalid's worries me. [ 1654.178654] SELinux: Context system_u:system_r:iceccd_untrusted_t:s0-s0:c0.c1023 became invalid (unmapped). [ 1654.346731] SELinux: Context system_u:system_r:httpd_mailgraph_script_t:s0-s0:c0.c1023 became invalid (unmapped). [ 1654.488142] SELinux: Context unconfined_u:system_r:iceccd_createenv_t:s0-s0:c0.c1023 became invalid (unmapped). [ 1654.701133] SELinux: Context unconfined_u:system_r:iceccd_untrusted_t:s0-s0:c0.c1023 became invalid (unmapped). [ 1654.774977] SELinux: Context system_u:system_r:iceccd_t:s0-s0:c0.c1023 became invalid (unmapped). [ 1654.841452] SELinux: Context system_u:system_r:httpd_queuegraph_script_t:s0-s0:c0.c1023 became invalid (unmapped). [ 1654.891749] SELinux: Context unconfined_u:system_r:httpd_mailgraph_script_t:s0-s0:c0.c1023 became invalid (unmapped). [ 1655.063715] SELinux: Context system_u:system_r:icecc_scheduler_t:s0-s0:c0.c1023 became invalid (unmapped). [ 1655.313795] SELinux: Context unconfined_u:system_r:iceccd_t:s0-s0:c0.c1023 became invalid (unmapped). [ 1655.367035] SELinux: Context unconfined_u:system_r:httpd_queuegraph_script_t:s0-s0:c0.c1023 became invalid (unmapped). [ 1655.458102] SELinux: Context system_u:system_r:iceccd_createenv_t:s0-s0:c0.c1023 became invalid (unmapped). [ 1655.588916] SELinux: Context unconfined_u:system_r:icecc_scheduler_t:s0-s0:c0.c1023 became invalid (unmapped). [ 1655.671764] SELinux: Context system_u:object_r:iceccd_var_run_t:s0 became invalid (unmapped).
iceccd_t does not come from the base policy. You need to open a new bug for the icecream pgk.
selinux-policy-3.12.1-135.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.