SELinux is preventing /usr/bin/pulseaudio from 'read' accesses on the file +sound:card29. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that pulseaudio should be allowed read access on the +sound:card29 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 pulseaudio /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context staff_u:staff_r:pulseaudio_t:s0-s0:c0.c1023 Target Context system_u:object_r:tmpfs_t:s0 Target Objects +sound:card29 [ file ] Source pulseaudio Source Path /usr/bin/pulseaudio Port <Neznámé> Host (removed) Source RPM Packages pulseaudio-0.9.22-3.fc15 Target RPM Packages Policy RPM selinux-policy-3.9.16-10.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 2.6.38.2-9.fc15.x86_64 #1 SMP Wed Mar 30 16:55:57 UTC 2011 x86_64 x86_64 Alert Count 5 First Seen Ne 3. duben 2011, 20:02:02 CEST Last Seen Ne 3. duben 2011, 23:22:31 CEST Local ID 1a60e6be-2b10-401b-970b-2613d660702b Raw Audit Messages type=AVC msg=audit(1301865751.883:82): avc: denied { read } for pid=2202 comm="pulseaudio" name="+sound:card29" dev=tmpfs ino=11259 scontext=staff_u:staff_r:pulseaudio_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmpfs_t:s0 tclass=file type=SYSCALL msg=audit(1301865751.883:82): arch=x86_64 syscall=open success=no exit=EACCES a0=7fff2b9e0770 a1=80000 a2=1b6 a3=615f6461706b6e69 items=0 ppid=2199 pid=2202 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm=pulseaudio exe=/usr/bin/pulseaudio subj=staff_u:staff_r:pulseaudio_t:s0-s0:c0.c1023 key=(null) Hash: pulseaudio,pulseaudio_t,tmpfs_t,file,read audit2allow #============= pulseaudio_t ============== allow pulseaudio_t tmpfs_t:file read; audit2allow -R #============= pulseaudio_t ============== allow pulseaudio_t tmpfs_t:file read;
I get this from audit2allow: bradford:~# ausearch -m AVC -ts recent|audit2allow #============= pulseaudio_t ============== allow pulseaudio_t tmpfs_t:file read; #============= staff_t ============== allow staff_t tmpfs_t:file read; #============= xdm_t ============== allow xdm_t tmpfs_t:file read; bradford:~#
The problem is /run/udev /run/initramfs /run/mdadm /run/plymouth remain labelled as tmpfs_t.
I think the problem is these dirs are created after mount -t tmpfs -o mode=0755,nodev,noexec,nosuid tmpfs /run >/dev/null 2>&1 and then systemd setup a label for /run.
Created attachment 489785 [details] Would this fix to dracut fix the labels.
systemd git now traverses through /run and relabels everything after loading the policy, much the same as with /dev. Will upload this tonight as systemd 23.
Dan, is your patch still necessary with current systemd? Harald, or maybe this is something to merge for you into dracut? (though I presume we don't actually use that dracut module on fedora, do we? Since systemd loads the policy, right?)
I guess as long as when SELinux policy is loaded the labels in /dev and /run are in a known good state, I don't care where this happens.
I am finally looking more at this. But I get after boot # ls -dZ /run/udev/* drwxr-xr-x. root root system_u:object_r:udev_var_run_t:s0 /run/udev/data drwxr-xr-x. root root system_u:object_r:udev_var_run_t:s0 /run/udev/links -rw-r--r--. root root system_u:object_r:udev_var_run_t:s0 /run/udev/queue.bin drwxr-xr-x. root root system_u:object_r:udev_var_run_t:s0 /run/udev/rules.d drwxr-xr-x. root root system_u:object_r:default_t:s0 /run/udev/tags drwxr-xr-x. root root system_u:object_r:default_t:s0 /run/udev/watch
default_t is the default label for a directory created under /. Once you have a directory labeled default_t all files created within that directory are labeled default_t. Any idea when where these directories get created and why their labeling was not fixed?
I am trying to find out where the problem is.
Nominating this as a beta blocker. http://fedoraproject.org/wiki/Fedora_15_Beta_Release_Criteria "In most cases, the installed system must be able to play back sound with gstreamer-based applications "
could this be related to my bug #694239 ?
No the problem is the directory /run/udev/tags and /run/udev/watch is not being setup by systemd/udev with the correct labels. The other problem is just that SELinux did not know that /var/run could be a symlink.
Lennart, Dan thinks this issue is on the systemd side; any ideas? this is probably the last real blocker for Beta, which we want to compose today.
These directories are set up in the initrd. But we do relabel them at boot from systemd, because we iterate through /run and fix all labels found there. In the plymouth case I might have a guess: it's the only process from the initrd that survives the transition to the main system, i.e. the only process started before the selinux policy is loaded until the end of the full boot process. But that doesn't really apply to udev and the others.
udev uses its internal function util_create_path() to create /run/udev/watch. This function is SELinux-aware: int util_create_path(..., const char *p) { ... udev_selinux_setfscreatecon(..., p, ...); mkdir(p, 0755); udev_selinux_resetfscreatecon(...) ... } void udev_selinux_setfscreatecon() { ... matchpathcon(...) setfscreatecon(...) ... } The problem is that matchpathcon won't tell udev about contexts of files outside of /dev, because udev initializes its SELinux usage with: matchpathcon_init_prefix(NULL, udev_get_dev_path(udev));
A quick and safe fix would be: - matchpathcon_init_prefix(NULL, udev_get_dev_path(udev)); + matchpathcon_init(NULL); in udev_selinux_init(). But it will probably make udev a bit slower. I don't see a reason why udev should be using a SELinux aware function to mkdir directories under /run/udev. A better fix would be to stop doing that.
That would make sense. Since it does not have labels for /run it is labeling them as default_t. Another option would be to have udev not set labels on anything other then /dev
with a test image that has a fix for 694239, I can confirm the incorrect labelling of these paths as default_t. It doesn't actually stop sound playback working on my test system, maybe the impact is hardware dependent? I see one avc for alsactl, but none for pulseaudio.
*** Bug 693581 has been marked as a duplicate of this bug. ***
Whats the AVC?
type=AVC msg=audit(1301960990.900:8): avc: denied { read } for pid=810 comm="NetworkManager" name="n2" dev=tmpfs ino=10770 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file
Kay will modify udev to fix labels only in /dev, and will omit any relabeling of /dev/.udev if udev ends up using that dir (which it normally won't).
awesome, this is now the last issue blocking Beta RC1 compose which is scheduled today, so a fix ASAP would be appreciated.
note we need to have a Fedora 15 udev package built with the fix and pushed as an update via Bodhi - thanks!
From Lennart on IRC: <mezcalero> 15:09:18> so kay is writing that patch now for upstream 15:09:22> but it's not trivial 15:09:33> and since he's not on fedora he cannot actually test this <mezcalero> 15:09:46> adamw: while we should have a patch later tonight 15:09:57> adamw: this is probably something hhoyer as udev maintainer has to look over 15:10:13> adamw: which means we won't be able to get you a working udev before tomorrow I am not exactly thrilled at the prospect of delaying the release for this. Could we just use mschmidt's workaround for now, until a 'correct' patch is available from upstream? We could patch that it and do a build in five minutes flat if we chose to.
I nominated this but I don't think it actually stops sound from working on my system and the person complaining about this in the forum didn't mention that either. I think this needn't be a blocker and we could do a proper patch and update post beta.
It's untested, I have no selinux running here. Please check: selinux: do not label files in runtime dir Do not label any files in the udev runtime directory, but only nodes, links and directories below /dev. In case the runtime directory falls back to /dev/.udev, label this directory once at udevd startup, but never anything below it. http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=51f43b53293c4cc64c2a55598491c6cbf27b6bd5;2
rahul: I'm kinda worried what else this may cause, though, it seems a pretty bad idea to have wrongly-labelled subdirs of /run .
udev-167-3.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/udev-167-3.fc15
So, bad news: the patch seems to be causing various issues in anaconda. See https://bugzilla.redhat.com/show_bug.cgi?id=694712 . We'll need upstream to take another look at it. In the short term, we have a few options here. We need to get an RC2 done today or we'll wind up slipping, I think. So, the options: 1) revert the patch and just ship like that; it seems no-one hit a definite blocker issue with the /run/udev/tags and /run/udev/watch subdirs being mislabelled. Obviously this leaves us open to any issues which do in fact arise due to those being mislabelled, which only further testing can determine. 2) revert the patch and go with mschmidt's 'safe' fix from comment #17. 3) try and get a revised patch from upstream today. 4) (if 3) fails) slip and wait for a revised patch from upstream. We should discuss this at the blocker meeting which is about to start.
Caveat: I just realized the live image I've been using to test the 'reverted udev' case also has anaconda 15.26, not 15.27. So I need to respin and confirm that it still works with anaconda 15.27. eta 15 mins.
Confirmed, anaconda 15.27 + reverted udev works. So the udev patch is definitely causing the problems.
We can't see anything in the udev code after the patch, which would label watch/ and tags/ incorrectly, like it did before. It also seems all to work fine on the installed system: $ /run/udev$ ls -alZ /run/udev/ drwxr-xr-x. root root system_u:object_r:udev_var_run_t:s0 ./ drwxr-xr-x. root root system_u:object_r:var_run_t:s0 ../ drwxr-xr-x. root root system_u:object_r:udev_var_run_t:s0 data/ drwxr-xr-x. root root system_u:object_r:udev_var_run_t:s0 links/ -rw-r--r--. root root system_u:object_r:udev_var_run_t:s0 queue.bin drwxr-xr-x. root root system_u:object_r:udev_var_run_t:s0 rules.d/ drwxr-xr-x. root root system_u:object_r:udev_var_run_t:s0 tags/ drwxr-xr-x. root root system_u:object_r:udev_var_run_t:s0 watch/ Please provide more details, what you see going wrong.
yeah, I'm afraid I was wrong: udev isn't actually the problem. turns out my live image had a couple other diffs against rc1, and re-spinning it with udev 167-3 doesn't hit the bug. false alarm! sorry again. Will follow up further in 694712. setting back to MODIFIED.
Discussed during the 2011-04-08 blocker review meeting [1]. Known consequences of 693247 not serious enough to be a Beta blocker: is a Final blocker per the SELinux avcs criterion. If further testing shows any more serious consequences of this bug, we can revisit it being a blocker. [1] http://meetbot.fedoraproject.org/fedora-bugzappers/2011-04-08/f-15-beta-blocker-review.2011-04-08-17.00.html
udev-167-3.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.