From: dac.override@gmail.com (Dominick Grift) Date: Wed, 14 Dec 2016 23:20:26 +0100 Subject: [refpolicy] [PATCH v2 1/5] wm: update the window manager (wm) module and enable its role template (v5) In-Reply-To: <713A6872-F7AA-4025-A4C0-A57761918BFF@trentalancia.net> 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> <713A6872-F7AA-4025-A4C0-A57761918BFF@trentalancia.net> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 12/14/2016 11:14 PM, Guido Trentalancia via refpolicy wrote: > I think that this should be avoided! > > The policy needs to be easy to read and understand, otherwise its purpose would be defeated. > Yes but in confined complex desktop environments there are complex requirements. Maintaining these things separately will have its drawbacks as well in the longer run. Whatever you decide, its fine by me. I am just trying to give you a glimpse of what you may expect as you go down the rabbit hole. > 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. > > _______________________________________________ > 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/20161214/b78f39ca/attachment.bin