From: dac.override@gmail.com (Dominick Grift) Date: Tue, 30 Aug 2016 21:21:48 +0200 Subject: [refpolicy] [PATCH v4] Update for the gnome policy and file contexts In-Reply-To: <1472584523.15862.10.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> <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: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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 > > Best regards, > > Guido > -- 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/20160830/c9528686/attachment-0001.bin