I needed to add following policy to allow chromium to work: allow chromium_t device_t:dir { add_name write remove_name }; allow chromium_t device_t:file { create read write open getattr }; allow chromium_renderer_t device_t:file { read append }; The device_t in question is /dev/shm . chromium error messages at launch look like this: [2432:2447:432339786:ERROR:shared_memory_posix.cc(171)] Creating shared memory in /dev/shm/.org.chromium.Chromium.VYEFxA failed: Permission denied [ 267.776569] type=1400 audit(1353271467.848:117): avc: denied { add_name } for pid=2291 comm="chrome" name=".org.chromium.Chromium.VYEFxA" scontext=unconfined_u:unconfined_r:chromium_t tcontext=system_u:object_r:device_t tclass=dir To test, launch chromium and make sure it can load web pages (e.g. gentoo.org). # ls -ldZ /dev/shm drwxrwxrwt. 2 root root system_u:object_r:device_t 5080 Nov 18 21:51 /dev/shm
/dev/shm should be tmpfs_t, not device_t... is it not a tmpfs mount on your system?
(In reply to comment #1) > /dev/shm should be tmpfs_t, not device_t... is it not a tmpfs mount on your > system? # grep shm /proc/mounts shm /dev/shm tmpfs rw,rootcontext=system_u:object_r:device_t,seclabel,nosuid,nodev,noexec,relatime 0 0 # grep shm /etc/fstab # grep shm -r /etc/selinux/targeted/ /etc/selinux/targeted/contexts/files/file_contexts:/dev/[shmxv]d[^/]* -b system_u:object_r:fixed_disk_device_t /etc/selinux/targeted/contexts/files/file_contexts:/dev/shm/.* <<none>> /etc/selinux/targeted/contexts/files/file_contexts:/lib/udev/devices/shm/.* <<none>> /etc/selinux/targeted/contexts/files/file_contexts:/dev/shm -d system_u:object_r:tmpfs_t /etc/selinux/targeted/contexts/files/file_contexts:/lib/udev/devices/shm -d system_u:object_r:tmpfs_t /etc/selinux/targeted/modules/active/file_contexts:/dev/[shmxv]d[^/]* -b system_u:object_r:fixed_disk_device_t /etc/selinux/targeted/modules/active/file_contexts:/dev/shm/.* <<none>> /etc/selinux/targeted/modules/active/file_contexts:/lib/udev/devices/shm/.* <<none>> /etc/selinux/targeted/modules/active/file_contexts:/dev/shm -d system_u:object_r:tmpfs_t /etc/selinux/targeted/modules/active/file_contexts:/lib/udev/devices/shm -d system_u:object_r:tmpfs_t /etc/selinux/targeted/modules/active/file_contexts.template:/dev/[shmxv]d[^/]* -b system_u:object_r:fixed_disk_device_t /etc/selinux/targeted/modules/active/file_contexts.template:/dev/shm/.* <<none>> /etc/selinux/targeted/modules/active/file_contexts.template:/lib/udev/devices/shm/.* <<none>> /etc/selinux/targeted/modules/active/file_contexts.template:/dev/shm -d system_u:object_r:tmpfs_t /etc/selinux/targeted/modules/active/file_contexts.template:/lib/udev/devices/shm -d system_u:object_r:tmpfs_t I'm not sure what's going on.
How is /dev/shm mounted on your system (i.e. who is responsible)? If the application isn't SELinux aware (for instance because its an linuxrc script in an initramfs) it will inherit the parent directory setting (device_t) and if you don't relabel afterwards, it'll remain as such. If it's udev though, it should be SELinux-aware (it runs setfscon after every change it does afaik).
(In reply to comment #3) > How is /dev/shm mounted on your system (i.e. who is responsible)? How do I check? I'm not using an initramfs. > If it's udev though, it should be SELinux-aware (it runs setfscon after > every change it does afaik). Hmm... restorecon /dev/shm fixes it for a while, but it doesn't persist across reboot. Is there any more info I could send to help debug this?
I think I got it. udev-mount runs restorecon -R on /dev but if /dev/shm was indeed only created just recently, then it inherits the device_t instead of becoming tmpfs_t. In enforcing mode, relabeling doesn't help since there is no association from tmpfs_t to device_t allowed (yet). With initramfs /dev/shm is mostly mounted in advance (or differently) which might make this issue not visible. If you allow the following, can you confirm that a reboot now has it marked as tmpfs_t? """ allow tmpfs_t device_t:filesystem associate; """
(In reply to comment #5) > I think I got it. udev-mount runs restorecon -R on /dev but if /dev/shm was > indeed only created just recently, then it inherits the device_t instead of > becoming tmpfs_t. In enforcing mode, relabeling doesn't help since there is > no association from tmpfs_t to device_t allowed (yet). Ah, I missed that part of udev-mount. Well, it turned out on my system it was not running restorecon at all, because /selinux does not exist on my system at that point. Here is the patch I've successfully applied to make it work. --- /etc/init.d/udev-mount.orig 2012-12-09 22:13:56.443997438 +0100 +++ /etc/init.d/udev-mount 2012-12-09 22:24:42.480983484 +0100 @@ -58,10 +58,9 @@ { mount_dev_directory || return 1 - # Selinux lovin; /selinux should be mounted by selinux-patched init - if [ -x /sbin/restorecon -a -c /selinux/null ]; then + if [ -x /sbin/restorecon ]; then HAVE_SELINUX=true - restorecon /dev > /selinux/null + restorecon /dev else HAVE_SELINUX=false fi > With initramfs /dev/shm is mostly mounted in advance (or differently) which > might make this issue not visible. > > If you allow the following, can you confirm that a reboot now has it marked > as tmpfs_t? > > """ > allow tmpfs_t device_t:filesystem associate; > """ That one by itself has no effect on the issue reported, and with the above patch is not needed.
Well, you can create /selinux (mkdir /selinux) for now and let /etc/init.d/procfs handle mounting selinuxfs on it. Not saying that's the solution, we shouldn't need /selinux anymore, but apparently that is why it doesn't fail on my tests here (my setup scripts had "mkdir /selinux" from the "old days" in it).
No need to wait for the stabilization in bug #511718 - /sys/fs/selinux is auto-mounted at start by init (well, by the SELinux code that init calls) anyway. Documentation is updated.
