From: dac.override@gmail.com (Dominick Grift) Date: Sun, 28 Aug 2016 10:03:17 +0200 Subject: [refpolicy] [PATCH v4] Update for the gnome policy and file contexts In-Reply-To: <6b1697f1-2aaf-3727-5b69-8794a0f85530@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> <1472334513.25935.16.camel@trentalancia.net> <6b1697f1-2aaf-3727-5b69-8794a0f85530@gmail.com> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 08/28/2016 09:24 AM, Dominick Grift wrote: > On 08/27/2016 11:48 PM, Guido Trentalancia via refpolicy wrote: >> Hello Dominick. >> >> Thanks for providing more information. >> >> 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. >> >> There must be a way of solving this problem. >> >>>> 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. >> >> In the case at hand, there isn't the need to get back to the initial >> domain. >> >> If I am not wrong, the whole transition is as follows: >> >> user_t (at_spi_exec_t)-> at_spi_t (dbusd_exec_t)-> session_dbusd_t >> (at_spi_exec_t)-> at_spi_t >> > > To see what i am trying to say you have to experience it for yourself. > Gnome is this single body made up of individual entities. Just because > atspi "may" not need to be prefixed doesnt mean that the session bus > doesnt need to be prefixed. atspi isnt the only app executed by the > session bus. > > And let me just remind you. atspi needs to be able to run the session > bus if it is not currently running. Do you see the chicken and egg problem? > > You have to see the bigger picture. That is why i suggested you confine a minimal desktop first before you start submitting patches. Because once you have a broad overview you will see important issues that need to be resolved. You aren't able to identify them if you do not look at this as a whole. Things should just naturally work. We can't have the house of cards collapse on the first anomaly that happens. >> The last transition is not working for some reason (I have used the new >> dbus interface quoted below)... >> >>>> 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 ?? >> >> [...] >> >>> Maybe others know a way out. I really don't. Sorry. >> >> Don't worry about that. But with the help of others, we need to find a >> cure for this ! >> >> Regards, >> >> Guido >> _______________________________________________ >> refpolicy mailing list >> refpolicy at oss.tresys.com >> http://oss.tresys.com/mailman/listinfo/refpolicy >> > > -- 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/20160828/6374cf5a/attachment.bin