I installed selinux-chromium for testing, and chromium failed to start in SELinux enforcing mode: $ chromium [2557:2557:1727940797:ERROR:process_singleton_linux.cc(263)] Failed to create /home/ph/.config/chromium/SingletonLock: Permission denied [2557:2557:1727941544:ERROR:chrome_browser_main.cc(1552)] Failed to create a ProcessSingleton for your profile directory. This means that running multiple instances would start multiple browser processes rather than opening a new window in the existing process. Aborting now to avoid profile corruption. audit messages: # audit2allow -d #============= chromium_t ============== allow chromium_t xdg_config_home_t:file create; allow chromium_t xdg_config_home_t:lnk_file { read create }; [ 107.872466] type=1400 audit(1348505952.982:67): avc: denied { read } for pid=2166 comm="chrome" name="SingletonLock" dev="sda1" ino=522327 scontext=unconfined_u:unconfined_r:chromium_t tcontext=unconfined_u:object_r:xdg_config_home_t tclass=lnk_file [ 107.873916] type=1400 audit(1348505952.983:68): avc: denied { create } for pid=2178 comm="Chrome_FileThre" name=".org.chromium.Chromium.ZO3dGF" scontext=unconfined_u:unconfined_r:chromium_t tcontext=unconfined_u:object_r:xdg_config_home_t tclass=file Now the problem is these files should have context chromium_xdg_config_t, but have xdg_config_home_t. Even deleting $HOME/.config/chromium and $HOME/.cache/chromium doesn't help. $ ls -lZd ~/.config/chromium/ drwx------. 2 ph ph unconfined_u:object_r:xdg_config_home_t 4096 Sep 24 19:22 /home/ph/.config/chromium/ I also tried "restorecon -R -F /home/ph", but that didn't help either. Here are relevant lines from /etc/selinux/targeted/contexts/files/file_contexts.homedirs: /home/[^/]*/.cache/chromium(/.*) unconfined_u:object_r:chromium_xdg_cache_t /home/[^/]*/.config/chromium(/.*) unconfined_u:object_r:chromium_xdg_config_t Just in case, here is the state of my chromium SELinux booleans: # semanage boolean -l | grep chromium chromium_manage_user_content (off , off) Allow chromium to write (manage) user content chromium_read_user_content (on , on) Allow chromium to read user content chromium_read_system_info (off , off) Allow chromium to read system information chromium_use_java (off , off) Allow the use of java plugins Note that the problem also occurs when setting chromium_manage_user_content to on.
I don't even get that far anymore, seems it wants to connect to dbus stuff here first (I don't have dbus running)... I looked at the policy and there should be an "automated" transition: """ hpl ~ # sesearch -s chromium_t -t xdg_config_home_t -d -T Found 1 named file transition filename_trans: type_transition chromium_t xdg_config_home_t : dir chromium_xdg_config_t "chromium"; """ So if chromium_t creates a directory in xdg_config_home_t, then this directory should be labeled chromium_xdg_config_t. Does sesearch say the same at your system?
(In reply to comment #1) > So if chromium_t creates a directory in xdg_config_home_t, then this > directory should be labeled chromium_xdg_config_t. Does sesearch say the > same at your system? Yes it does. The transition doesn't seem to work though (or maybe the reason is different). Anyway, when I deleted ~/.{config,cache}/chromium and started chromium in SELinux permissive mode, ~/.config/chromium still has xdg_config_home_t context. Just in case, I'm using Linux kernel 3.4.5-hardened.
One reason could be that the creation of the directory isn't done under chromium_t. Can you enable a (temporary) policy with: """ auditallow domain xdg_config_home_t:dir create_dir_perms """ and then check the audit log for information about the domain creating the chromium directory? Once you have it, remove the policy again from the system (don't need this cluttering your audit log for long).
Here is the policy I ended up loading: module ph-local 1.0; require { class dir { getattr create }; attribute domain; type xdg_config_home_t; } auditallow domain xdg_config_home_t:dir { getattr create }; I removed ~/.config/chromium and ~/.cache/chromium, then started the browser in enforcing mode. It did create ~/.config/chromium, but with xdg_config_home_t context. Audit logs: [48921.755956] type=1400 audit(1348554766.865:319): avc: granted { getattr } for pid=4558 comm="chrome" path="/home/ph/.config" dev="sda1" ino=522249 scontext=unconfined_u:unconfined_r:chromium_t tcontext=unconfined_u:object_r:xdg_config_home_t tclass=dir [48921.780343] type=1400 audit(1348554766.890:320): avc: denied { create } for pid=4558 comm="chrome" name="SingletonLock" scontext=unconfined_u:unconfined_r:chromium_t tcontext=unconfined_u:object_r:xdg_config_home_t tclass=lnk_file [48921.781697] type=1400 audit(1348554766.891:321): avc: denied { create } for pid=4569 comm="Chrome_FileThre" name=".org.chromium.Chromium.eDM2VV" scontext=unconfined_u:unconfined_r:chromium_t tcontext=unconfined_u:object_r:xdg_config_home_t tclass=file [48921.782041] type=1400 audit(1348554766.892:322): avc: denied { create } for pid=4569 comm="Chrome_FileThre" name=".org.chromium.Chromium.xwBF0E" scontext=unconfined_u:unconfined_r:chromium_t tcontext=unconfined_u:object_r:xdg_config_home_t tclass=file
Hmm, perhaps we need to add in the add_entry_dir_perms to see the creation of the directory. I tested here locally (a small change in policy was needed to interact with dbus) and everything still works as planned, with the right context being created.
(In reply to comment #5) > Hmm, perhaps we need to add in the add_entry_dir_perms to see the creation > of the directory. [49324.051529] type=1400 audit(1348555169.161:851): avc: granted { search } for pid=4653 comm="chrome" name=".config" dev="sda1" ino=522249 scontext=unconfined_u:unconfined_r:chromium_t tcontext=unconfined_u:object_r:xdg_config_home_t tclass=dir [49324.051540] type=1400 audit(1348555169.161:852): avc: granted { write search } for pid=4653 comm="chrome" name=".config" dev="sda1" ino=522249 scontext=unconfined_u:unconfined_r:chromium_t tcontext=unconfined_u:object_r:xdg_config_home_t tclass=dir [49324.051549] type=1400 audit(1348555169.161:853): avc: granted { add_name search } for pid=4653 comm="chrome" name="chromium" scontext=unconfined_u:unconfined_r:chromium_t tcontext=unconfined_u:object_r:xdg_config_home_t tclass=dir I also noticed this: [49324.053578] type=1400 audit(1348555169.163:855): avc: granted { search } for pid=2153 comm="restorecond" name=".config" dev="sda1" ino=522249 scontext=unconfined_u:unconfined_r:unconfined_t tcontext=unconfined_u:object_r:xdg_config_home_t tclass=dir So there might be some slight possibility restorecond is messing something on my system.
Normally, restorecond only watches files matched by its configuration file (/etc/selinux/restorecond.conf). But I would imagine it uses the file context definitions available on the system. """ testsys ~ # grep chromium_xdg_config_t /etc/selinux/*/contexts/files/* /etc/selinux/strict/contexts/files/file_contexts.homedirs: /home/[^/]*/.config/chromium(/.*) user_u:object_r:chromium_xdg_config_t /etc/selinux/strict/contexts/files/file_contexts.homedirs: /root/.config/chromium(/.*) root:object_r:chromium_xdg_config_t """
# grep chromium_xdg_config_t /etc/selinux/*/contexts/files/* /etc/selinux/strict/contexts/files/file_contexts.homedirs:/home/[^/]*/.config/chromium(/.*) user_u:object_r:chromium_xdg_config_t /etc/selinux/strict/contexts/files/file_contexts.homedirs:/root/.config/chromium(/.*) root:object_r:chromium_xdg_config_t /etc/selinux/targeted/contexts/files/file_contexts.homedirs:/home/[^/]*/.config/chromium(/.*) unconfined_u:object_r:chromium_xdg_config_t Note I'm using the targeted policy. It's also weird to my why an explicit restorecon on /home/ph/.config/chromium fails to set unconfined_u:object_r:chromium_xdg_config_t context.
Aha... I think I found it, the ".config" and ".cache" in the contexts file should be "\.config" and "\.cache", otherwise the . operator is considered as a wildcard, so the regular xdg contexts take precedence...
Fixed in live ebuilds, will be part of r6
In hardened-dev, r6 release
In main tree, ~arch'ed
(In reply to comment #12) > In main tree, ~arch'ed With sec-policy/selinux-chromium-2.20120725-r7 I can successfully run "restorecon -R -F /home/ph" with _existing_ .config/chromium, .cache/chromium dirs and they get correct context. However, when those dirs do not exist, they are still created with the wrong context, resulting in poor out-of-the-box experience. Please let me know if you need more info from my system. Thank you for the progress on this bug.
With .config existing, but no .config/chromium, or even with no .config. Afaik, when ~/.config and ~/.cache exist (and are labeled xdg_config_home_t and xdg_config_cache_t) then they should be created automatically with the right context.
With no .config chromium also fails to start: [15675:15675:54835999725:FATAL:chrome_browser_main.cc(1214)] Check failed: PathService::Get(chrome::DIR_USER_DATA, &user_data_dir_). Must be able to get user data directory! Aborted [15679:15679:54836090571:ERROR:zygote_linux.cc(505)] write: Broken pipe $ ls -ldZ .config ls: cannot access .config: No such file or directory It actually fails to create .config if it's not there: # src="chromium_t" tgt="user_home_dir_t" class="dir", perms="create" # comm="chrome" exe="" path="" allow chromium_t user_home_dir_t:dir create; [54835.999683] type=1400 audit(1353326036.070:6909): avc: denied { create } for pid=15675 comm="chrome" name=".config" scontext=unconfined_u:unconfined_r:chromium_t tcontext=unconfined_u:object_r:user_home_dir_t tclass=dir I wonder why there are such discrepancies between your system and mine...
# sesearch -s chromium_t -t xdg_config_home_t -SCAT Found 2 semantic av rules: allow chromium_t xdg_config_home_t : file { ioctl read getattr lock open } ; allow chromium_t xdg_config_home_t : dir { ioctl read write getattr lock add_name remove_name search open } ; Found 1 named file transition filename_trans: type_transition chromium_t xdg_config_home_t : dir chromium_xdg_config_t "chromium"; It makes sense that it can't create .config (unless chromium_manage_user_content is set). But if .config exists, and it is labeled xdg_config_home_t, the above rules do allow it to write into a xdg_config_home_t directory, and if it creates a directory in .config called "chromium" then that directory gets labeled chromium_xdg_config_t. So, if .config exists and you relabel it (so it gets labeled xdg_config_home_t), can you then clean up your avc log, start chromium and see what it all sais (and denies)?
(In reply to comment #16) > # sesearch -s chromium_t -t xdg_config_home_t -SCAT > Found 2 semantic av rules: > allow chromium_t xdg_config_home_t : file { ioctl read getattr lock open > } ; > allow chromium_t xdg_config_home_t : dir { ioctl read write getattr lock > add_name remove_name search open } ; > > > Found 1 named file transition filename_trans: > type_transition chromium_t xdg_config_home_t : dir chromium_xdg_config_t > "chromium"; Same on my system. > It makes sense that it can't create .config (unless > chromium_manage_user_content is set). It fails for me even with chromium_manage_user_content on. > So, if .config exists and you relabel it (so it gets labeled > xdg_config_home_t), can you then clean up your avc log, start chromium and > see what it all sais (and denies)? Interesting. I started with no .config, manually created it (mkdir .config), it got a correct label (unconfined_u:object_r:xdg_config_home_t) and then chromium started successfully. Now the remaining case is one where there is no .config initially I think.
Yup. Most likely I'll need to allow whatever user domain an automated file transition when creating a .config directory in user_home_dir_t.
Should be in the policy in the repo. I couldn't introduce the automated file transition for all domains as that would provide too much power to other, unrelated applications. But for chromium, it should be in (I'll fix other apps later).
r9 in hardened-dev overlay
r9 in main repo, ~arch'ed
Forgot to mention... stabilized a while ago ;)
