From: pebenito@ieee.org (Chris PeBenito) Date: Wed, 14 Dec 2016 17:07:27 -0500 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: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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. -- Chris PeBenito