Description of problem: colord upstream fails to work in enforcing mode. Version-Release number of selected component (if applicable): selinux-policy-3.9.16-23.fc15.noarch How reproducible: Always Steps to Reproduce: 1. Download colord from git master and switch to fd-passing branch 2. Compile, run and watch make check fall over Additional info: colord is now using the fd passing feature in dbus to pass an opened FD from the session to the system process so it can be parsed. If the daemon sees a fd, it uses this instead of the filename. This saves one open call, and probably can limit further the permissions needed by colord as it's no longer opening files in $home. I'm not completely sure about the "use vector for unconfined_t on file descriptors" but it's what walters says I need. Advice welcome. Thanks. Richard. p.s. There was no AVC when I switched to using fd-passing, the dbus daemon just dropped my message on the floor and the client program hung. This probably isn't the best failure mode... Using "setenforce 0" made everything magically work.
I'm not sure this is colord specific at all. Either way, SELinux must not randomly cause dbus-daemon to just drop messages at the floor just because there's a file-descriptor attached to the message. Especially not without logging it. File-descriptor passing needs to work out of the box for *any* application using the system-, session- or peer-to-peer connections - not just colord.
Richard are you able to test the following?: mkdir ~/mytest; echo "policy_module(mytest, 1.0.0) gen_require(\` type system_dbusd_t; ') userdom_use_unpriv_users_fds(system_dbusd_t)" > mytest.te; make -f /usr/share/selinux/devel/Makefile mytest.pp sudo semodule -i mytest.pp sudo semodule -DB < reproduce the issue: see if this makes it work in enforcing mode> ausearch -m avc -ts recent (if it does not work please enclose output of this command) after testing you could remove the test module: sudo semodule -r mytest and rebuild the policy with dontaudits re-inserted: sudo semodule -B
Yes I would like to see what this is causing for an AVC?
Created attachment 500493 [details] ausearch output Enabling the new module does not fix the hang in gnome-settings-daemon. I've attached the output of ausearch as requested. This is a fairly up to date F15 system, certainly updated in the last week or so. If you want me to do any further testing that's no problem as well. What's more worrying for me as a software developer is that the client is just hanging forever, rather than returning with a nice error. I guess in the Fedora package for gnome-settings-daemon I'll just have to conflict with old versions of the selinux-policy package to avoid having systems that are locked up on login. Better ideas welcome. Thanks for any help.
I do not see any file descriptor issue in that log only attempts by colord_t to read /home/hughsie/Code/colord/data/tests/ibm-t61.icc. Am i right to assume that this might have caused the "hang" and that colord needs to be able to read files in the user home directory? Can you please do the following: semodule -r mytest (if you hadńt done so already) semodule -DB (to unload any hidden denial rules) make a note of the system time (date) setenforce 0 (for testing purposes) reproduce the issue ausearch -m avc -ts $date (where date is the "noted system time", example ausearch -m avc -ts 12:04) ausearch -m user_avc -ts $date (where date is the "noted system time", example ausearch -m avc -ts 12:04) setenforce 1 (back to enforcing) semodule -B (reinsert the hidden denial rules) Thank you for testing
dwalsh: You committed this recently: http://git.fedorahosted.org/git/?p=selinux-policy.git;a=commitdiff;h=8803af737e8beed4110840fa0ccb5f83c177d493 Was that with regard to this bug? The AVC denials that Richard enclosed give a wrong impression. (I think he fell victim to the "no policycoreutils-restorecond installed" bug. I think we are dealing with this here: http://www.freedesktop.org/wiki/OpenIcc#OpenICCproject This is what i am currently seeing: avc: denied { read } for pid=939 comm="dbus-daemon" path="/home/dgrift/.local/share/icc/edid-0a027915105823af34f99b1704e80336.icc" dev=dm-3 ino=6030362 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:data_home_t:s0 tclass=file I would suggest we create a type "icc_data_home_t" for openicc content there by implementing a name filetrans for "icc" directories in "data_home_t" locations and allow system_dbusd_t to "gnome_read_inherited_user_openicc_content()" Please see my enclosed patch "0001-Implement-a-type-for-freedesktop-openicc-standard-.l.patch"
Created attachment 503104 [details] implement openicc Basically this patch creates a new "gnome_home_type" called icc_data_home_t for ~/.local/share/icc(/.*)? Added a named file transition for it in "gnome_filetrans_home_content" Allows colord_t to read gnome icc data home content. Allows system_dbusd_t to read inherited gnome icc data home files. Untested at the moment but i have this installed and will see if it deals with the issues. The patch also reverts http://git.fedorahosted.org/git/?p=selinux-policy.git;a=commitdiff;h=8803af737e8beed4110840fa0ccb5f83c177d493 or atleast the part applicable to colord.
Seems to work fine here. Although for some (probably unrelated) reason gcm-prefs crashed with a segfault.
Created attachment 503111 [details] [ retry ] Implement openicc I changed a couple of things. colord seems to no longer need to be able to read gconf_home_t files (are now icc_data_home_t) Add search gconfd_home_t and data_home_t directories to gnome_read_home_icc_data_content so that colord can actually get to that. Could not find any trace of "colord needing to "use" *any* file descriptors other than what is allowed already. Enclosed path seems to work for me. Richard when you test your icc profiles please either put them in ~/.local/share/icc if possible or label the profile .icc file icc_data_home_t (or if my patch is not accepted label it data_home_t "chcon -t data_home_t ~/mytest/bla.icc")
Well, this patch is maybe for rawhide but I am still fine with userdom_read_inherited_user_home_content_files(colord_t) optional_policy(` gnome_read_gconf_home_files(colord_t) ') in F15.
(In reply to comment #10) > Well, this patch is maybe for rawhide but I am still fine with Yes imaginable since f15 does not do the named file trans dance, and even then it is a matter of opinion whether its worth disallowing daemons access to generic home/data_home content. > > > userdom_read_inherited_user_home_content_files(colord_t) This is not needed for colord, and if it is then it also needs open i think (see richards AVC denial) > > optional_policy(` > gnome_read_gconf_home_files(colord_t) > ') system_dbusd_t will need to read inherited data_home_t files as well i think (see my avc denils above) > > in F15.
(In reply to comment #9) > Could not find any trace of "colord needing to "use" *any* file descriptors > other than what is allowed already. If you're using colord >= 0.1.8 instead of reading the files from the users home directory, the session process opens a FD and passes this instead to the daemon. I think that's a whole lot more sane than introducing a icc_data_home_t type. colord should never have needed the gconf_home_t at all. When I'm testing the "sending a fd" functionality here, the dbus daemon refuses the message with: type=AVC msg=audit(1307355898.199:93): avc: denied { read } for pid=915 comm="dbus-daemon" path="/home/hughsie/.local/share/icc/2007WFP.icm" dev=dm-0 ino=790853 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:data_home_t:s0 tclass=file which causes gcm-session to fall on it's face as dbus does not send an error or any success message. The intention is that colord just gets the fd which has been dup()ed by dbus. Richard.
Well yes that is what i encountered as well: avc: denied { read } for pid=939 comm="dbus-daemon" path="/home/dgrift/.local/share/icc/edid-0a027915105823af34f99b1704e80336.icc" dev=dm-3 ino=6030362 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:data_home_t:s0 tclass=file And that is also what my patch fixes. icc_data_home_t is, in my view, still optimal though. Since system_dbusd_t needs to read the .icc/.icm file as you can see in the AVC denials. It is my opinion to narrow that down to just the icc content rather than any generic content in ~/.local/share.* But i will leave that decision to dwalsh of course. So in resume: userdom_read_inherited_user_home_content_files(colord_t) optional_policy(` gnome_read_gconf_home_files(colord_t) ') Can both be removed. And: allow system_dbusd_t data_home_t:file read; is what needs to be added. And if we implement type icc_data_home_t then we can do this instead: allow system_dbusd_t icc_data_home_t:file read;
(In reply to comment #13) > And if we implement type icc_data_home_t then we can do this instead: > allow system_dbusd_t icc_data_home_t:file read; You probably want to add /home/hughsie/.color/icc/* to icc_data_home_t as well then -- this is the legacy directory also searched for in the session that will not exist on new installs. Any imported home directories from Fedora 10 to Fedora 13 will probably have this directory present, although it might not have any profiles actually installed there unless the user manually put files there. Richard.
Yes sure not a problem, I will wait and see if dwalsh thinks its worth to implement icc_data_home_t in Fedora16 and produce an updated patch if needed. in Fedora 15 we probably just want: allow system_dbusd_t data_home_t:file read; Since else we will run into labelling issues once again. But i personally prefer icc_data_home_t because i would not want to allow system_dbusd_t to read inherited generic data home files. Not only because of that but from the freedesktop site i get the impression that some apps may need to be able to interact that icc content as well, and i would like to anticipate that.
(In reply to comment #15) > ...Not only because of > that but from the freedesktop site i get the impression that some apps may need > to be able to interact that icc content as well, and i would like to anticipate > that. Yes, seems sane to me. Apps like firefox, gimp, eog etc will want to read those profiles, and more and more programs in the future will need them (metacity etc). Richard.
I am fine with this.
I agree.
Why does this show up as { read } and not simply { use }?
(In reply to comment #19) > Why does this show up as { read } and not simply { use }? Ok, in current Linus git, SELinux does: selinux_file_receive(file) { return file_has_perm(current_cred(), file, file_to_av(file)); } Where file_to_av() looks at the state of the file (in this case, the descriptor is open for reading). However, this is lame because dbus isn't *actually* calling read(). It simply is getting a reference to the fd. Can we change this to SECURITY_FD_USE instead of file_to_av()?
Added Kernel guys to comment on Colin's question.
SELinux checks whether a process has the rights to use an open file descriptor in accordance with its open file flags when the descriptor is opened, received over a socket, or inherited across exec. That's really the only sane way to ensure that the file can't ever be used by an unauthorized process. Yes, we also apply checks on read/write() to support revocation upon relabel or policy change, but we want to prevent the descriptor from being added to the process' table unless it has sufficient rights in the first place.
(In reply to comment #22) > SELinux checks whether a process has the rights to use an open file descriptor > in accordance with its open file flags when the descriptor is opened, received > over a socket, or inherited across exec. That's really the only sane way to > ensure that the file can't ever be used by an unauthorized process. Yes, we > also apply checks on read/write() to support revocation upon relabel or policy > change, but we want to prevent the descriptor from being added to the process' > table unless it has sufficient rights in the first place. I understand the rationale behind not adding it to the process table; my question was more about why isn't the permission simply { use }. Anyways, we probably can't change it now, even if we agreed it did make sense. So...I guess we just have to live with it.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping