From: guido@trentalancia.net (Guido Trentalancia) Date: Wed, 14 Dec 2016 23:14:38 +0100 Subject: [refpolicy] [PATCH v2 1/5] wm: update the window manager (wm) module and enable its role template (v5) In-Reply-To: References: <1481130053.3300.9.camel@trentalancia.net> <1481217618.20182.8.camel@trentalancia.net> <1481322107.2989.1.camel@trentalancia.net> <1481676520.17446.9.camel@trentalancia.net> <1481680495.3551.1.camel@trentalancia.net> <1481726222.4419.9.camel@trentalancia.net> <1481729627.14900.7.camel@trentalancia.net> <327faf4c-0676-abc3-fa8f-90f1b7b8a952@ieee.org> <5c4ca0ef-3ab6-ffb4-9a1c-a0a1402b0e5b@gmail.com> Message-ID: <713A6872-F7AA-4025-A4C0-A57761918BFF@trentalancia.net> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com I think that this should be avoided! The policy needs to be easy to read and understand, otherwise its purpose would be defeated. Guido On the 14th December 2016 23:07:27 CET, Chris PeBenito via refpolicy wrote: >On 12/14/16 16:52, Dominick Grift via refpolicy wrote: >> On 12/14/2016 10:45 PM, Dominick Grift wrote: >>> On 12/14/2016 10:34 PM, Dominick Grift wrote: >>>> On 12/14/2016 10:23 PM, Chris PeBenito via refpolicy wrote: >>>>> On 12/14/16 10:33, Guido Trentalancia via refpolicy wrote: > >[...] > >>>>>> and then, for each application that you want to enable from the >window >>>>>> manager, you need to call the interface wm_application_domain() >from >>>>>> the application module similarly to the way the >>>>>> userdom_user_application_domain() interface is currently called. >>>>>> >>>>>> For example, for mozilla: >>>>>> >>>>>> [cut] >>>>>> >>>>>> --- >refpolicy-git-orig/policy/modules/contrib/mozilla.te 2016-12-09 >22:29:53.579462880 +0100 >>>>>> +++ refpolicy-git/policy/modules/contrib/mozilla.te 2016-12-14 >16:28:46.055294184 +0100 >>>>>> @@ -22,6 +39,7 @@ type mozilla_exec_t; >>>>>> typealias mozilla_t alias { user_mozilla_t staff_mozilla_t >sysadm_mozilla_t }; >>>>>> typealias mozilla_t alias { auditadm_mozilla_t secadm_mozilla_t >}; >>>>>> userdom_user_application_domain(mozilla_t, mozilla_exec_t) >>>>>> +wm_application_domain(mozilla_t, mozilla_exec_t) >>>>> >>>>> I'd tend to prefer it this way, as long as you make this call >optional. >>>> >>>> In the bigger picture this solution is a bit unwieldy in my view. >There >>>> are various components that need to be able to run programs on >behalf of >>>> the user. In this case it is gnome shell, but for example systemd >--user >>>> needs the same, and there are various other instances. >>>> >>>> The solution i have in dssp is not perfect either. But for domain >>>> transitions that apply to more than the just shell i >>>> use a type attribute. >>>> >>>> example: mozilla_run(staff_type_attribute, role_attribute) >>>> >>>> Then i associate the type attribute also with the programs that >need to >>>> be able to run the programs on behalf of the user. >>>> >>>> staff_type(staff_wm_t) >>>> staff_type(staff_systemd_t) >>>> >>>> It is not perfect either but atleast it provides a single point of >>>> failure. domain transitions apply automatically to all domains that >need >>>> to be able to run programs on behalf of the user > >The Fedora policy has had this concept for a long time and I never >liked >it. It makes it much less obvious what a domain can do by looking at >the policy sources. It's easy to overlook the staff_type() call you >have above, and even if you see it, it may be hard to understand what >that truly implies. > >I still feel that is the case, but it may be time to do it anyway. If >so, it would have to be only in a limited way, for example only for >domain transitions.