From mboxrd@z Thu Jan 1 00:00:00 1970 From: guido@trentalancia.net (Guido Trentalancia) Date: Sun, 28 Aug 2016 17:37:13 +0200 Subject: [refpolicy] [PATCH v4] Update for the gnome policy and file contexts In-Reply-To: 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: <7EAFAD82-CDDA-47E3-950E-4D5610686C6C@trentalancia.net> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Things are very far from working naturally as they are. On the other hand, the patches are surely far from being complete or stable yet, but at least every version allows to start the Gnome desktop. Now I met this major problem, it looks by all means a limitation of the existing framework, but I am sure that it will be sorted out... I am also waiting to hear from Christopher about this. Regards, Guido On the 28th of August 2016 10:03:17 CEST, Dominick Grift via refpolicy wrote: >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 >>> >> >>