From: dac.override@gmail.com (Dominick Grift) Date: Sat, 27 Aug 2016 22:57:43 +0200 Subject: [refpolicy] [PATCH v4] Update for the gnome policy and file contexts In-Reply-To: <1472330498.25935.7.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> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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 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 ?? > > Regards, > > Guido > Maybe others know a way out. I really don't. Sorry. -- 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/20160827/ce13f8cd/attachment.bin