From: guido@trentalancia.net (Guido Trentalancia) Date: Sat, 27 Aug 2016 23:48:33 +0200 Subject: [refpolicy] [PATCH v4] Update for the gnome policy and file contexts In-Reply-To: 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> <1471956294.17467.4.camel@trentalancia.net> <1472075733.19800.4.camel@trentalancia.net> <1472317696.28955.1.camel@trentalancia.net> <1472318213.31962.2.camel@trentalancia.net> <1472330498.25935.7.camel@trentalancia.net> Message-ID: <1472334513.25935.16.camel@trentalancia.net> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Hello Dominick. Thanks for providing more information. On Sat, 27/08/2016 at 22.57 +0200, Dominick Grift wrote: > On 08/27/2016 10:41 PM, Guido Trentalancia wrote: > > > > On Sat, 27/08/2016 at 19.17 +0200, Dominick Grift wrote: > > > > > > On 08/27/2016 07:16 PM, Guido Trentalancia wrote: > > > > [...] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It's not so helpful unfortunately.??My guess is that it > > > > > > > is a > > > > > > > conflicting? > > > > > > > type_transition.??Unfortunately the compiler error > > > > > > > message > > > > > > > isn't > > > > > > > helpful. > > > > > > > > > > > > I have just posted a patch on the SELinux mailing list to > > > > > > produce a > > > > > > more meaningful error message for conflicting type rules, > > > > > > see > > > > > > the > > > > > > following thread: > > > > > > > > > > > > [PATCH] libsepol: Produce more meaningful error messages > > > > > > for > > > > > > conflicting type rules > > > > > > > > > > > > In this case, the conflicting type rule is: > > > > > > > > > > > > scontext=at_spi_t > > > > > > tcontext=dbusd_exec_t > > > > > > tclass=process > > > > > > result=sysadm_dbusd_t > > > > > > > > > > > > which confirms the previous debugging results (it's the > > > > > > type_transition > > > > > > rule). > > > > > > > > > > > > Another one is similar, with scontext=gnome_settings_t. > > > > > > > > > > > > What I suspect is that when it compiles, it quadruplicates > > > > > > the > > > > > > type > > > > > > transition for each of user, staff, sysadm and xguest, thus > > > > > > leading > > > > > > to > > > > > > conflicting rules. > > > > > > > > > > > > Therefore, the solution might be to use a common static > > > > > > name > > > > > > for > > > > > > the > > > > > > domain (for example, "session_dbusd_t" instead of > > > > > > "$1_dbusd_t"). > > > > > > > > > > and that will introduce other issues. because the session bus > > > > > must be > > > > > able to run things on behalf of the caller > > > > > > > > Thanks for providing a forecast of other issues. > > > > > > > > So, what's the way out of this damn loop ? > > > > > > > > I am almost getting lost... > > > > > > > > > > I dont know. > > > > We need to find a cure for this !! > > I have been pleading for this for years. In my case the solution to > these problems is DSSP and CIL. I was never able to solve these > issues > with reference policy unfortunately. There must be a way of solving this problem. > > What prevents it from running things on behalf of the caller ? And > > what > > do you mean exactly for running things on behalf of the caller ? > > It hard to explain. The best way to appreciate what I mean is to > experience it yourself. It will become clear as you move towards a > fully > confined desktop. > > A lot of programs can be started by the session bus. Many of these > programs started by the session bus on behalf of users run other > programs and so forth and so forth. Some of these programs need to > eventually be able run shell with a domain transition back to the > login > shell domain. > > staff_t -> staff_dbus_t -> staff_myapp_t -> staff_t > > To be able to do this we need to use derived types. You can't do it > if > theres a single session_dbus_t type. In the case at hand, there isn't the need to get back to the initial domain. If I am not wrong, the whole transition is as follows: user_t (at_spi_exec_t)-> at_spi_t (dbusd_exec_t)-> session_dbusd_t (at_spi_exec_t)-> at_spi_t The last transition is not working for some reason (I have used the new dbus interface quoted below)... > > I have the following interface: > > > > allow $1 dbusd_exec_t:file exec_file_perms; > > domtrans_pattern($1, dbusd_exec_t, session_dbusd_t) > > > > which is called with $1=at_spi_t and $1=gnome_settings_t but goes > > completely ignored ! > > > > If I search for "execute" or "transition" permissions using > > sesearch, > > it doesn't find anything, so for some strange reason the interface > > goes > > ?completely ignored ! > > > > Is that what you meant earlier ? Why is it happening ?? [...] > Maybe others know a way out. I really don't. Sorry. Don't worry about that. But with the help of others, we need to find a cure for this ! Regards, Guido