[refpolicy] [PATCH v2 1/5] wm: update the window manager (wm) module and enable its role template (v5)

[dac.override@gmail.com (Dominick Grift)]

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