From: jason@perfinion.com (Jason Zaman) Date: Thu, 1 Sep 2016 19:53:29 +0800 Subject: [refpolicy] [PATCH v4] Update for the gnome policy and file contexts In-Reply-To: <1472722380.6210.17.camel@trentalancia.net> References: <1471099545.21480.27.camel@trentalancia.net> <1471296811.28802.0.camel@trentalancia.net> <1471704772.17584.9.camel@trentalancia.net> <1471894798.19333.1.camel@trentalancia.net> <20160901042035.GA23615@meriadoc.perfinion.com> <1472722380.6210.17.camel@trentalancia.net> Message-ID: <20160901115329.GA9845@meriadoc.perfinion.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Thu, Sep 01, 2016 at 11:33:00AM +0200, Guido Trentalancia wrote: > Hello Jason. > > On Thu, 01/09/2016 at 12.20 +0800, Jason Zaman wrote: > > On Mon, Aug 22, 2016 at 09:39:58PM +0200, Guido Trentalancia wrote: > > > > > > Update for the gnome module: > > [...] > > > Hey, > > > > I've been fairly busy lately so didnt closely follow this thread and > > its > > too long now for me to understand what exactly the problems are. > > I'll point you to a few right messages to read in this thread to > understand the problem clearly... > > Please read the following messages in order: > > http://oss.tresys.com/pipermail/refpolicy/2016-August/008360.html?(non- > quoted message text only) > > http://oss.tresys.com/pipermail/refpolicy/2016-August/008369.html?(non- > quoted message text only) > > What Dominick added here is partly true, although at the I have had > some success with re-writing the policy for the whole desktop (or most > of it): > > http://oss.tresys.com/pipermail/refpolicy/2016-August/008370.html > > http://oss.tresys.com/pipermail/refpolicy/2016-August/008374.html > > http://oss.tresys.com/pipermail/refpolicy/2016-August/008382.html > > http://oss.tresys.com/pipermail/refpolicy/2016-August/008385.html > > http://oss.tresys.com/pipermail/refpolicy/2016-August/008384.html > > The following messages are about a possible way to solve the problem > without changing the actual policy (which can be tricky): > > http://oss.tresys.com/pipermail/refpolicy/2016-August/008397.html > > http://oss.tresys.com/pipermail/refpolicy/2016-August/008398.html > > http://oss.tresys.com/pipermail/refpolicy/2016-August/008400.html > > So, you have an excellent excerpt now... This helped a lot but I am still unclear what the original problem is. > > If I followed correctly, it seems like the biggest problem currently > > is > > transitioning to/from dbus? can you show the "ps auxfZ | grep dbus" > > lines? > > The problem is transitioning from a user domain (user, staff, sysadm or > xguest) to other domains such as dbus (or gkeyring) and then back to > the initial user domain. > > At the moment the policy uses variable types built using the user > argument ($1) passed to the gnome/dbus role() interface. > > Such approach has big limitations and the current framework is poorly > designed with respect to the ability to perform the above mentioned > transition. As you realized, this kind if thing is not allowed: type_transition session_dbusd_t bin_t:process user_t; type_transition session_dbusd_t bin_t:process staff_t; type_transition session_dbusd_t bin_t:process sysadm_t; type_transition session_dbusd_t bin_t:process xguest_t; There are typically two ways to fix it, the easiest is prefixed types so that the transitions become: type_transition user_dbusd_t bin_t:process user_t; type_transition staff_dbusd_t bin_t:process staff_t; dbus is currently setup like this along with most other kinds of programs that need their own domain but then need to transition back to the user's shell (eg staff_sudo_t, and a few login type things are what first come to mind). The other way is to have the program be selinux aware. Ie link with libselinux and query the policy for what should be used. For example, when running a user's cronjob, cron will look in /etc/selinux/mcs/contexts/default_contexts for the line and query all the role/type combos until it finds one that is allowed by the policy for that user. For these kinds of things the program basically does setexeccon() before the exec to manually set it so do not require the type_transition rules at all. DBus is also SELinux aware and it looks like logic for something like this might already exist. On my system I have: /etc/selinux/mcs/contexts/dbus_contexts but it's empty so not sure what should be in it. There are many ways to fix a problem like this depending on a lot of things. > > > How exactly are you running into problems? Can you post a very > > minimal > > command that triggers the problems? Is there some hello world I can > > put > > in /usr/share/dbus-1/services and a command to trigger the issue? > > It's more complex than just starting a command. There are problems in > the underlying framework when the modified policy is loaded > (conflicting type rules, i.e. conflicting type transitions). > > One way to solve the problem is by changing the policy. I have had some > success so far, however it's tricky, expensive and it's not the optimal > solution. > > A possible optimal solution is proposed in the last two or three > messages that I posted (see the last two or three messages quoted > above). I still do not understand exactly what problem you are trying to solve tho. What is running and what is it trying to do? Can you show some error messages? Are these lines the ones that are giving issues? Why do you need the lines at all? dbus_domain_transition(at_spi_t, user_dbusd_t) dbus_domain_transition(gnome_settings_t, user_dbusd_t) Wouldnt they just need dbus send_msg? Why does it need to exec the dbus daemon? It should already be running, they dont need to start it or anything. Can you show some error messages? > > A lot of these other problems in this patch seem to be issues with > > dbus > > so lets fix that first then the other ones will be easier. > > If you want to help implementing a patch, we need to identify the code > where such policy is actually enforced, so that there we can track the > calling user domain to choose the right type transition. We need to take a step back, there are too many issues mixed together with this patch. fixing the policy to allow conflicting types sounds like the wrong solution to whatever the problem is. -- Jason > Regards, > > Guido