From: dac.override@gmail.com (Dominick Grift) Date: Wed, 31 Aug 2016 08:55:24 +0200 Subject: [refpolicy] [PATCH v4] Update for the gnome policy and file contexts In-Reply-To: <5f8f9330-0b7f-ca89-2cc8-d965711e4f98@ieee.org> 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> <5f8f9330-0b7f-ca89-2cc8-d965711e4f98@ieee.org> Message-ID: <8377fd00-1aa2-6f10-1520-28d32207ca13@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 08/30/2016 11:39 PM, Chris PeBenito wrote: > 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. > > Sure. That is true. Maybe the ability to structure your policy better makes a big difference, aside from having the luxury of more meaningful compiler errors and warnings. -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160831/f4aabd70/attachment-0001.bin