From: pebenito@ieee.org (Chris PeBenito) Date: Tue, 30 Aug 2016 17:39:26 -0400 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> <1472584523.15862.10.camel@trentalancia.net> Message-ID: <5f8f9330-0b7f-ca89-2cc8-d965711e4f98@ieee.org> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 08/30/16 15:21, Dominick Grift via refpolicy wrote: > On 08/30/2016 09:15 PM, Guido Trentalancia wrote: >> Hello Dominick. >> >> 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. >>> >>>> >>>> >>>> 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. >> >> I am hitting a similar situation at the moment with the modified gnome >> and dbus modules... >> >> user_t -> session_dbusd_t -> cannot execute bin_t or shell in the >> user_t domain >> >> Perhaps, it is possible to change the existing code so that it adds the >> conflicting type rules, but then when it actually needs to apply them, >> it looks up for duplicates and it only applies the one which matches >> the calling context. >> >> It should be feasible... >> >> What do you say ? >> > > I am saying what I said. This issue is very old and no one ever bothered > to fix it. It is not going to happen. > > Module policy is legacy. A new superior language that does not have > these issues is available. > >> We need to find a way out of this ! > > There is a way out but its not module policy Perhaps you can structure the policy better, but a conflicting type transition is an error even if is written in CIL. -- Chris PeBenito