From: dac.override@gmail.com (Dominick Grift) Date: Wed, 31 Aug 2016 09:31:30 +0200 Subject: [refpolicy] [PATCH v4] Update for the gnome policy and file contexts In-Reply-To: <8377fd00-1aa2-6f10-1520-28d32207ca13@gmail.com> 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> <8377fd00-1aa2-6f10-1520-28d32207ca13@gmail.com> Message-ID: <14029d1d-e851-93d1-04c5-3ad5607b6462@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 08/31/2016 08:55 AM, Dominick Grift wrote: > 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. > Not suggesting secilc is perfect. It is not. SECILC should identify and warn about any blockabstracts it finds in optional policy. Currently it allows them without any notification that it is not allowed and/or that it causes inconsistent behavior. This is bound to cause confusion. Even though these are documented "rules". The compiler should still catch it and prevent it from happening. -- 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/b130d02a/attachment.bin