From: dac.override@gmail.com (Dominick Grift) Date: Wed, 14 Dec 2016 23:13:46 +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: <0717327c-a49c-8ef1-4300-35ec50594622@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 12/14/2016 11:07 PM, Chris PeBenito 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 agree. It needs to be used with great care and it is certainly not a perfect solution either. > 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. > In DSSP1 i use run interfaces. this is a bit more than strictly needed because all the domains that need to run stuff on behalf of users can then also read state and send signals, but i think its a reasonable trade off. The most compelling argument for this solution is the single point of failure argument. Down the road with many programs this might really make things more manage-able. The argument to not do it is that one really needs to be careful that one doesnt use this attribute for anything else, and that you'll lose some flexibility. > -- 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/20161214/1ec33cae/attachment.bin