This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 706975

Summary: colord needs the "use" vector for unconfined_t on file descriptors
Product: [Fedora] Fedora Reporter: Richard Hughes <rhughes>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 15CC: davidz, dominick.grift, dwalsh, eparis, mgrepl, richard, sds, walters
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-07 15:58:35 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
ausearch output
none
implement openicc
none
[ retry ] Implement openicc none

Description Richard Hughes 2011-05-23 12:34:09 EDT
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.
Comment 1 David Zeuthen 2011-05-23 12:43:50 EDT
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.
Comment 2 Dominick Grift 2011-05-23 13:04:32 EDT
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
Comment 3 Daniel Walsh 2011-05-23 15:21:51 EDT
Yes I would like to see what this is causing for an AVC?
Comment 4 Richard Hughes 2011-05-23 15:52:41 EDT
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.
Comment 5 Dominick Grift 2011-05-23 16:54:46 EDT
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
Comment 6 Dominick Grift 2011-06-05 13:20:25 EDT
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"
Comment 7 Dominick Grift 2011-06-05 13:25:31 EDT
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.
Comment 8 Dominick Grift 2011-06-05 13:44:05 EDT
Seems to work fine here. Although for some (probably unrelated) reason gcm-prefs crashed with a segfault.
Comment 9 Dominick Grift 2011-06-05 14:20:07 EDT
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")
Comment 10 Miroslav Grepl 2011-06-06 04:30:33 EDT
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.
Comment 11 Dominick Grift 2011-06-06 04:41:39 EDT
(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.
Comment 12 Richard Hughes 2011-06-06 06:45:06 EDT
(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.
Comment 13 Dominick Grift 2011-06-06 06:59:43 EDT
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;
Comment 14 Richard Hughes 2011-06-06 07:04:23 EDT
(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.
Comment 15 Dominick Grift 2011-06-06 07:16:39 EDT
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.
Comment 16 Richard Hughes 2011-06-06 07:30:58 EDT
(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.
Comment 17 Miroslav Grepl 2011-06-06 07:42:58 EDT
I am fine with this.
Comment 18 Daniel Walsh 2011-06-06 12:07:06 EDT
I agree.
Comment 19 Colin Walters 2011-07-13 17:09:12 EDT
Why does this show up as { read } and not simply { use }?
Comment 20 Colin Walters 2011-07-13 17:35:40 EDT
(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()?
Comment 21 Daniel Walsh 2011-07-14 10:29:34 EDT
Added Kernel guys to comment on Colin's question.
Comment 22 Stephen Smalley 2011-07-14 10:53:19 EDT
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.
Comment 23 Colin Walters 2011-07-14 15:28:32 EDT
(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.
Comment 24 Fedora End Of Life 2012-08-07 15:58:37 EDT
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