[refpolicy] [PATCH] xserver: add r/w permissions for the DRI devices

[refpolicy] [PATCH] xserver: add r/w permissions for the DRI devices

[Guido Trentalancia]

Modify the xserver role, so that the Direct Rendering Infrastructure
devices can be opened read/write (used for graphic acceleration,
for example, by Mesa/libGL).

Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
---
 policy/modules/services/xserver.if |    2 ++
 1 file changed, 2 insertions(+)

--- refpolicy-git-06082016-orig/policy/modules/services/xserver.if	2016-08-06 21:26:43.295774282 +0200
+++ refpolicy-git-06082016/policy/modules/services/xserver.if	2016-08-19 15:52:41.712830041 +0200
@@ -163,6 +163,8 @@ interface(`xserver_role',`
 	relabel_dirs_pattern($2, user_fonts_config_t, user_fonts_config_t)
 	relabel_files_pattern($2, user_fonts_config_t, user_fonts_config_t)
 
+	# for the accelerated graphic drivers
+	dev_rw_dri($2)
 ')
 
 #######################################

[refpolicy] [PATCH] xserver: add r/w permissions for the DRI devices

[Chris PeBenito]

On 08/20/16 10:52, Guido Trentalancia wrote:
> Modify the xserver role, so that the Direct Rendering Infrastructure
> devices can be opened read/write (used for graphic acceleration,
> for example, by Mesa/libGL).
>
> Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
> ---
>  policy/modules/services/xserver.if |    2 ++
>  1 file changed, 2 insertions(+)
>
> --- refpolicy-git-06082016-orig/policy/modules/services/xserver.if	2016-08-06 21:26:43.295774282 +0200
> +++ refpolicy-git-06082016/policy/modules/services/xserver.if	2016-08-19 15:52:41.712830041 +0200
> @@ -163,6 +163,8 @@ interface(`xserver_role',`
>  	relabel_dirs_pattern($2, user_fonts_config_t, user_fonts_config_t)
>  	relabel_files_pattern($2, user_fonts_config_t, user_fonts_config_t)
>
> +	# for the accelerated graphic drivers
> +	dev_rw_dri($2)
>  ')
>
>  #######################################

I'm fine with this change, but I think it should be conditional.  Then 
people that don't want users to have direct access to hardware, like 
this, can disable it.

-- 
Chris PeBenito

[refpolicy] [PATCH] xserver: add r/w permissions for the DRI devices

[Jason Zaman]

On Mon, Aug 22, 2016 at 08:52:38PM -0400, Chris PeBenito wrote:
> On 08/20/16 10:52, Guido Trentalancia wrote:
> > Modify the xserver role, so that the Direct Rendering Infrastructure
> > devices can be opened read/write (used for graphic acceleration,
> > for example, by Mesa/libGL).
> >
> > Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
> > ---
> >  policy/modules/services/xserver.if |    2 ++
> >  1 file changed, 2 insertions(+)
> >
> > --- refpolicy-git-06082016-orig/policy/modules/services/xserver.if	2016-08-06 21:26:43.295774282 +0200
> > +++ refpolicy-git-06082016/policy/modules/services/xserver.if	2016-08-19 15:52:41.712830041 +0200
> > @@ -163,6 +163,8 @@ interface(`xserver_role',`
> >  	relabel_dirs_pattern($2, user_fonts_config_t, user_fonts_config_t)
> >  	relabel_files_pattern($2, user_fonts_config_t, user_fonts_config_t)
> >
> > +	# for the accelerated graphic drivers
> > +	dev_rw_dri($2)
> >  ')
> >
> >  #######################################
> 
> I'm fine with this change, but I think it should be conditional.  Then 
> people that don't want users to have direct access to hardware, like 
> this, can disable it.

I have this locally as dev_rw_dri(x_domain) instead. since chromium_t
and mplayer_t and other things than just the user roles need hardware
acceleration.
I agree it should be in a boolean too since i have not found anything
that *requires* it, and people might want it off.

-- Jason
> 
> -- 
> Chris PeBenito
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

[refpolicy] [PATCH] xserver: add r/w permissions for the DRI devices

[Dominick Grift]

On 08/23/2016 12:30 PM, Jason Zaman wrote:
> On Mon, Aug 22, 2016 at 08:52:38PM -0400, Chris PeBenito wrote:
>> On 08/20/16 10:52, Guido Trentalancia wrote:
>>> Modify the xserver role, so that the Direct Rendering Infrastructure
>>> devices can be opened read/write (used for graphic acceleration,
>>> for example, by Mesa/libGL).
>>>
>>> Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
>>> ---
>>>  policy/modules/services/xserver.if |    2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> --- refpolicy-git-06082016-orig/policy/modules/services/xserver.if	2016-08-06 21:26:43.295774282 +0200
>>> +++ refpolicy-git-06082016/policy/modules/services/xserver.if	2016-08-19 15:52:41.712830041 +0200
>>> @@ -163,6 +163,8 @@ interface(`xserver_role',`
>>>  	relabel_dirs_pattern($2, user_fonts_config_t, user_fonts_config_t)
>>>  	relabel_files_pattern($2, user_fonts_config_t, user_fonts_config_t)
>>>
>>> +	# for the accelerated graphic drivers
>>> +	dev_rw_dri($2)
>>>  ')
>>>
>>>  #######################################
>>
>> I'm fine with this change, but I think it should be conditional.  Then 
>> people that don't want users to have direct access to hardware, like 
>> this, can disable it.
> 
> I have this locally as dev_rw_dri(x_domain) instead. since chromium_t
> and mplayer_t and other things than just the user roles need hardware
> acceleration.
> I agree it should be in a boolean too since i have not found anything
> that *requires* it, and people might want it off.
> 

I suspect that this is also (or also can be) driver specific

> -- Jason
>>
>> -- 
>> Chris PeBenito
>> _______________________________________________
>> refpolicy mailing list
>> refpolicy at oss.tresys.com
>> http://oss.tresys.com/mailman/listinfo/refpolicy
> _______________________________________________
> 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/20160823/d24fd527/attachment.bin 

[refpolicy] [PATCH] xserver: add r/w permissions for the DRI devices

[Guido Trentalancia]

On Mon, 22/08/2016 at 20.52 -0400, Chris PeBenito wrote:
> On 08/20/16 10:52, Guido Trentalancia wrote:
> > 
> > Modify the xserver role, so that the Direct Rendering
> > Infrastructure
> > devices can be opened read/write (used for graphic acceleration,
> > for example, by Mesa/libGL).
> > 
> > Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
> > ---
> > ?policy/modules/services/xserver.if |????2 ++
> > ?1 file changed, 2 insertions(+)
> > 
> > --- refpolicy-git-06082016-orig/policy/modules/services/xserver.if	
> > 2016-08-06 21:26:43.295774282 +0200
> > +++ refpolicy-git-06082016/policy/modules/services/xserver.if	
> > 2016-08-19 15:52:41.712830041 +0200
> > @@ -163,6 +163,8 @@ interface(`xserver_role',`
> > ?	relabel_dirs_pattern($2, user_fonts_config_t,
> > user_fonts_config_t)
> > ?	relabel_files_pattern($2, user_fonts_config_t,
> > user_fonts_config_t)
> > 
> > +	# for the accelerated graphic drivers
> > +	dev_rw_dri($2)
> > ?')
> > 
> > ?#######################################
> 
> I'm fine with this change, but I think it should be
> conditional.??Then?
> people that don't want users to have direct access to hardware, like?
> this, can disable it.

What's the point ? DRI can already be disabled in the X server
configuration file easily and using it should not pose a security risk.

So, why increasing the complexity for little or no gain ?

Regards,

Guido

[refpolicy] [PATCH] xserver: add r/w permissions for the DRI devices

[Dominick Grift]

On 08/23/2016 03:21 PM, Guido Trentalancia wrote:
> On Mon, 22/08/2016 at 20.52 -0400, Chris PeBenito wrote:
>> On 08/20/16 10:52, Guido Trentalancia wrote:
>>>
>>> Modify the xserver role, so that the Direct Rendering
>>> Infrastructure
>>> devices can be opened read/write (used for graphic acceleration,
>>> for example, by Mesa/libGL).
>>>
>>> Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
>>> ---
>>>  policy/modules/services/xserver.if |    2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> --- refpolicy-git-06082016-orig/policy/modules/services/xserver.if	
>>> 2016-08-06 21:26:43.295774282 +0200
>>> +++ refpolicy-git-06082016/policy/modules/services/xserver.if	
>>> 2016-08-19 15:52:41.712830041 +0200
>>> @@ -163,6 +163,8 @@ interface(`xserver_role',`
>>>  	relabel_dirs_pattern($2, user_fonts_config_t,
>>> user_fonts_config_t)
>>>  	relabel_files_pattern($2, user_fonts_config_t,
>>> user_fonts_config_t)
>>>
>>> +	# for the accelerated graphic drivers
>>> +	dev_rw_dri($2)
>>>  ')
>>>
>>>  #######################################
>>
>> I'm fine with this change, but I think it should be
>> conditional.  Then 
>> people that don't want users to have direct access to hardware, like 
>> this, can disable it.
> 
> What's the point ? DRI can already be disabled in the X server
> configuration file easily and using it should not pose a security risk.
> 
> So, why increasing the complexity for little or no gain ?

https://en.wikipedia.org/wiki/Principle_of_least_privilege

The login shell does not need to read/write dri devices.

> 
> Regards,
> 
> Guido
> _______________________________________________
> 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/20160823/efa6e258/attachment.bin 

[refpolicy] [PATCH] xserver: add r/w permissions for the DRI devices

[Guido Trentalancia]

If you are only using the shell, then you should not load the xserver module in the first place! 

On the 23rd august 2016 15:28:37 CEST, Dominick Grift <dac.override@gmail.com> wrote:
>On 08/23/2016 03:21 PM, Guido Trentalancia wrote:
>> On Mon, 22/08/2016 at 20.52 -0400, Chris PeBenito wrote:
>>> On 08/20/16 10:52, Guido Trentalancia wrote:
>>>>
>>>> Modify the xserver role, so that the Direct Rendering
>>>> Infrastructure
>>>> devices can be opened read/write (used for graphic acceleration,
>>>> for example, by Mesa/libGL).
>>>>
>>>> Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
>>>> ---
>>>>  policy/modules/services/xserver.if |    2 ++
>>>>  1 file changed, 2 insertions(+)
>>>>
>>>> --- refpolicy-git-06082016-orig/policy/modules/services/xserver.if	
>>>> 2016-08-06 21:26:43.295774282 +0200
>>>> +++ refpolicy-git-06082016/policy/modules/services/xserver.if	
>>>> 2016-08-19 15:52:41.712830041 +0200
>>>> @@ -163,6 +163,8 @@ interface(`xserver_role',`
>>>>  	relabel_dirs_pattern($2, user_fonts_config_t,
>>>> user_fonts_config_t)
>>>>  	relabel_files_pattern($2, user_fonts_config_t,
>>>> user_fonts_config_t)
>>>>
>>>> +	# for the accelerated graphic drivers
>>>> +	dev_rw_dri($2)
>>>>  ')
>>>>
>>>>  #######################################
>>>
>>> I'm fine with this change, but I think it should be
>>> conditional.  Then 
>>> people that don't want users to have direct access to hardware, like
>
>>> this, can disable it.
>> 
>> What's the point ? DRI can already be disabled in the X server
>> configuration file easily and using it should not pose a security
>risk.
>> 
>> So, why increasing the complexity for little or no gain ?
>
>https://en.wikipedia.org/wiki/Principle_of_least_privilege
>
>The login shell does not need to read/write dri devices.
>
>> 
>> Regards,
>> 
>> Guido
>> _______________________________________________
>> refpolicy mailing list
>> refpolicy at oss.tresys.com
>> http://oss.tresys.com/mailman/listinfo/refpolicy
>> 

[refpolicy] [PATCH] xserver: add r/w permissions for the DRI devices

[Dominick Grift]

On 08/23/2016 03:34 PM, Guido Trentalancia wrote:
> If you are only using the shell, then you should not load the xserver module in the first place!

It is very hard to justify my POV in reference policy. Because LP is not
enforced consistently.

The xserver_role() is, I think, supposed to be called from a (login)
shell domain.

If you allow the login shell domain to rw dri devices then you have some
processes running in the login shell domain that shouldnt be running
there in the first place in an ideal world.

Refpolicy has to strike a delicate balance. On the one hand it has to be
usable but on the other hand it needs to be relevant base.

Making this conditional is not perfect but its a reasonable compromise.

> 
> On the 23rd august 2016 15:28:37 CEST, Dominick Grift <dac.override@gmail.com> wrote:
>> On 08/23/2016 03:21 PM, Guido Trentalancia wrote:
>>> On Mon, 22/08/2016 at 20.52 -0400, Chris PeBenito wrote:
>>>> On 08/20/16 10:52, Guido Trentalancia wrote:
>>>>>
>>>>> Modify the xserver role, so that the Direct Rendering
>>>>> Infrastructure
>>>>> devices can be opened read/write (used for graphic acceleration,
>>>>> for example, by Mesa/libGL).
>>>>>
>>>>> Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
>>>>> ---
>>>>>  policy/modules/services/xserver.if |    2 ++
>>>>>  1 file changed, 2 insertions(+)
>>>>>
>>>>> --- refpolicy-git-06082016-orig/policy/modules/services/xserver.if	
>>>>> 2016-08-06 21:26:43.295774282 +0200
>>>>> +++ refpolicy-git-06082016/policy/modules/services/xserver.if	
>>>>> 2016-08-19 15:52:41.712830041 +0200
>>>>> @@ -163,6 +163,8 @@ interface(`xserver_role',`
>>>>>  	relabel_dirs_pattern($2, user_fonts_config_t,
>>>>> user_fonts_config_t)
>>>>>  	relabel_files_pattern($2, user_fonts_config_t,
>>>>> user_fonts_config_t)
>>>>>
>>>>> +	# for the accelerated graphic drivers
>>>>> +	dev_rw_dri($2)
>>>>>  ')
>>>>>
>>>>>  #######################################
>>>>
>>>> I'm fine with this change, but I think it should be
>>>> conditional.  Then 
>>>> people that don't want users to have direct access to hardware, like
>>
>>>> this, can disable it.
>>>
>>> What's the point ? DRI can already be disabled in the X server
>>> configuration file easily and using it should not pose a security
>> risk.
>>>
>>> So, why increasing the complexity for little or no gain ?
>>
>> https://en.wikipedia.org/wiki/Principle_of_least_privilege
>>
>> The login shell does not need to read/write dri devices.
>>
>>>
>>> Regards,
>>>
>>> Guido
>>> _______________________________________________
>>> 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/20160823/1ea00cb4/attachment.bin 

[refpolicy] [PATCH] xserver: add r/w permissions for the DRI devices

[Dominick Grift]

On 08/23/2016 03:34 PM, Guido Trentalancia wrote:
> If you are only using the shell, then you should not load the xserver module in the first place! 

I can imagine that this is hard to comprehend. It helps to see the
bigger picture. Imagine a system where every single process is
associated with a set of permissions that is tailored exactly to what
the process needs.

This is impossible in GNU/Linux, right? There is just too much code. How
can we target each and every process imaginable? We can't.

The purpose of reference policy is to be a usable base. That means that
refpolicy cannot afford to make too many assumptions.

Now lets look at the xserver_role() interface. You are basically
suggesting that we allow whoever calls this interface to read/write dri
devices. This is a bad idea because: 1. It limits to use of this
interface because you can only call it when the calling domain needs to
be able to read/write dri devices (unless you dont care about least
privilege). 2. Whatever calls this interface runs in a domain of its
own. So ideally this permissions should be associated with that domain
instead in the module where the domain is declared.

So ideally this shouldn't be needed, but we don't live in an ideal
world, and so reference policy is willing to compromise.

To keep you happy who ever calls this interface can conditionally be
allowed to read/write dri. So that you don't have to enforce least
privilege. It is made conditionally so that the audience that does want
to enforce least privilege is not forced into an impossible situation.

Is it ideal? No its not. Is refpolicy in a tough spot? For sure.

One might still not understand what i am trying to explain above. I
don't blame one because it is pretty confusing. It is actually so
confusing and so complex that even the best fall into this trap
occasionally.

Also you can say well its not a threat, but you don't know everyone's
threat model. One should try not to assume. One doesn't have to. Live is
so much easier if you can afford sticking to least privilege
consistently, because at least then you have some stability. A process
needs something or it doesn't. There is no grey areas  there.

Okay thats just my rant, and as always. My opinions are my own.

> 
> On the 23rd august 2016 15:28:37 CEST, Dominick Grift <dac.override@gmail.com> wrote:
>> On 08/23/2016 03:21 PM, Guido Trentalancia wrote:
>>> On Mon, 22/08/2016 at 20.52 -0400, Chris PeBenito wrote:
>>>> On 08/20/16 10:52, Guido Trentalancia wrote:
>>>>>
>>>>> Modify the xserver role, so that the Direct Rendering
>>>>> Infrastructure
>>>>> devices can be opened read/write (used for graphic acceleration,
>>>>> for example, by Mesa/libGL).
>>>>>
>>>>> Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
>>>>> ---
>>>>>  policy/modules/services/xserver.if |    2 ++
>>>>>  1 file changed, 2 insertions(+)
>>>>>
>>>>> --- refpolicy-git-06082016-orig/policy/modules/services/xserver.if	
>>>>> 2016-08-06 21:26:43.295774282 +0200
>>>>> +++ refpolicy-git-06082016/policy/modules/services/xserver.if	
>>>>> 2016-08-19 15:52:41.712830041 +0200
>>>>> @@ -163,6 +163,8 @@ interface(`xserver_role',`
>>>>>  	relabel_dirs_pattern($2, user_fonts_config_t,
>>>>> user_fonts_config_t)
>>>>>  	relabel_files_pattern($2, user_fonts_config_t,
>>>>> user_fonts_config_t)
>>>>>
>>>>> +	# for the accelerated graphic drivers
>>>>> +	dev_rw_dri($2)
>>>>>  ')
>>>>>
>>>>>  #######################################
>>>>
>>>> I'm fine with this change, but I think it should be
>>>> conditional.  Then 
>>>> people that don't want users to have direct access to hardware, like
>>
>>>> this, can disable it.
>>>
>>> What's the point ? DRI can already be disabled in the X server
>>> configuration file easily and using it should not pose a security
>> risk.
>>>
>>> So, why increasing the complexity for little or no gain ?
>>
>> https://en.wikipedia.org/wiki/Principle_of_least_privilege
>>
>> The login shell does not need to read/write dri devices.
>>
>>>
>>> Regards,
>>>
>>> Guido
>>> _______________________________________________
>>> 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/20160823/202cae8a/attachment.bin 

[refpolicy] [PATCH] xserver: add r/w permissions for the DRI devices

[Guido Trentalancia]

On Tue, 23/08/2016 at 16.15 +0200, Dominick Grift wrote:
> On 08/23/2016 03:34 PM, Guido Trentalancia wrote:
> > 
> > If you are only using the shell, then you should not load the
> > xserver module in the first place!?
> 
> I can imagine that this is hard to comprehend. It helps to see the
> bigger picture. Imagine a system where every single process is
> associated with a set of permissions that is tailored exactly to what
> the process needs.
> 
> This is impossible in GNU/Linux, right? There is just too much code.
> How
> can we target each and every process imaginable? We can't.
> 
> The purpose of reference policy is to be a usable base. That means
> that
> refpolicy cannot afford to make too many assumptions.
> 
> Now lets look at the xserver_role() interface. You are basically
> suggesting that we allow whoever calls this interface to read/write
> dri
> devices. This is a bad idea because: 1. It limits to use of this
> interface because you can only call it when the calling domain needs
> to
> be able to read/write dri devices (unless you dont care about least
> privilege). 2. Whatever calls this interface runs in a domain of its
> own. So ideally this permissions should be associated with that
> domain
> instead in the module where the domain is declared.
> 
> So ideally this shouldn't be needed, but we don't live in an ideal
> world, and so reference policy is willing to compromise.
> 
> To keep you happy who ever calls this interface can conditionally be
> allowed to read/write dri. So that you don't have to enforce least
> privilege. It is made conditionally so that the audience that does
> want
> to enforce least privilege is not forced into an impossible
> situation.
> 
> Is it ideal? No its not. Is refpolicy in a tough spot? For sure.
> 
> One might still not understand what i am trying to explain above. I
> don't blame one because it is pretty confusing. It is actually so
> confusing and so complex that even the best fall into this trap
> occasionally.
> 
> Also you can say well its not a threat, but you don't know everyone's
> threat model. One should try not to assume. One doesn't have to. Live
> is
> so much easier if you can afford sticking to least privilege
> consistently, because at least then you have some stability. A
> process
> needs something or it doesn't. There is no grey areas??there.
> 
> Okay thats just my rant, and as always. My opinions are my own.
> 
> > 
> > 
> > On the 23rd august 2016 15:28:37 CEST, Dominick Grift <dac.override
> > @gmail.com> wrote:
> > > 
> > > On 08/23/2016 03:21 PM, Guido Trentalancia wrote:
> > > > 
> > > > On Mon, 22/08/2016 at 20.52 -0400, Chris PeBenito wrote:
> > > > > 
> > > > > On 08/20/16 10:52, Guido Trentalancia wrote:
> > > > > > 
> > > > > > 
> > > > > > Modify the xserver role, so that the Direct Rendering
> > > > > > Infrastructure
> > > > > > devices can be opened read/write (used for graphic
> > > > > > acceleration,
> > > > > > for example, by Mesa/libGL).
> > > > > > 
> > > > > > Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
> > > > > > ---
> > > > > > ?policy/modules/services/xserver.if |????2 ++
> > > > > > ?1 file changed, 2 insertions(+)
> > > > > > 
> > > > > > --- refpolicy-git-06082016-
> > > > > > orig/policy/modules/services/xserver.if	
> > > > > > 2016-08-06 21:26:43.295774282 +0200
> > > > > > +++ refpolicy-git-
> > > > > > 06082016/policy/modules/services/xserver.if	
> > > > > > 2016-08-19 15:52:41.712830041 +0200
> > > > > > @@ -163,6 +163,8 @@ interface(`xserver_role',`
> > > > > > ?	relabel_dirs_pattern($2, user_fonts_config_t,
> > > > > > user_fonts_config_t)
> > > > > > ?	relabel_files_pattern($2, user_fonts_config_t,
> > > > > > user_fonts_config_t)
> > > > > > 
> > > > > > +	# for the accelerated graphic drivers
> > > > > > +	dev_rw_dri($2)
> > > > > > ?')
> > > > > > 
> > > > > > ?#######################################
> > > > > 
> > > > > I'm fine with this change, but I think it should be
> > > > > conditional.??Then?
> > > > > people that don't want users to have direct access to
> > > > > hardware, like
> > > 
> > > > 
> > > > > 
> > > > > this, can disable it.
> > > > 
> > > > What's the point ? DRI can already be disabled in the X server
> > > > configuration file easily and using it should not pose a
> > > > security
> > > risk.
> > > > 
> > > > 
> > > > So, why increasing the complexity for little or no gain ?
> > > 
> > > https://en.wikipedia.org/wiki/Principle_of_least_privilege
> > > 
> > > The login shell does not need to read/write dri devices.

This patch can be dropped because it is not strictly needed to run the
X server.

--
Guido

[refpolicy] [PATCH] xserver: add r/w permissions for the DRI devices

[Chris PeBenito]

On 08/23/16 09:21, Guido Trentalancia wrote:
> On Mon, 22/08/2016 at 20.52 -0400, Chris PeBenito wrote:
>> On 08/20/16 10:52, Guido Trentalancia wrote:
>>>
>>> Modify the xserver role, so that the Direct Rendering
>>> Infrastructure
>>> devices can be opened read/write (used for graphic acceleration,
>>> for example, by Mesa/libGL).
>>>
>>> Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
>>> ---
>>>  policy/modules/services/xserver.if |    2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> --- refpolicy-git-06082016-orig/policy/modules/services/xserver.if	
>>> 2016-08-06 21:26:43.295774282 +0200
>>> +++ refpolicy-git-06082016/policy/modules/services/xserver.if	
>>> 2016-08-19 15:52:41.712830041 +0200
>>> @@ -163,6 +163,8 @@ interface(`xserver_role',`
>>>  	relabel_dirs_pattern($2, user_fonts_config_t,
>>> user_fonts_config_t)
>>>  	relabel_files_pattern($2, user_fonts_config_t,
>>> user_fonts_config_t)
>>>
>>> +	# for the accelerated graphic drivers
>>> +	dev_rw_dri($2)
>>>  ')
>>>
>>>  #######################################
>>
>> I'm fine with this change, but I think it should be
>> conditional.  Then
>> people that don't want users to have direct access to hardware, like
>> this, can disable it.
>
> What's the point ? DRI can already be disabled in the X server
> configuration file easily and using it should not pose a security risk.
>
> So, why increasing the complexity for little or no gain ?

In this case, it has little to do with the X server.  $2 is a user 
domain, so you're saying any app the user can run (in the user's domain) 
can rw the DRI device.

-- 
Chris PeBenito

[refpolicy] [PATCH] xserver: add r/w permissions for the DRI devices

[Guido Trentalancia]

Hello Christopher.

On Tue, 23/08/2016 at 18.53 -0400, Chris PeBenito wrote:
> On 08/23/16 09:21, Guido Trentalancia wrote:
> > 
> > On Mon, 22/08/2016 at 20.52 -0400, Chris PeBenito wrote:
> > > 
> > > On 08/20/16 10:52, Guido Trentalancia wrote:
> > > > 
> > > > 
> > > > Modify the xserver role, so that the Direct Rendering
> > > > Infrastructure
> > > > devices can be opened read/write (used for graphic
> > > > acceleration,
> > > > for example, by Mesa/libGL).
> > > > 
> > > > Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
> > > > ---
> > > > ?policy/modules/services/xserver.if |????2 ++
> > > > ?1 file changed, 2 insertions(+)
> > > > 
> > > > --- refpolicy-git-06082016-
> > > > orig/policy/modules/services/xserver.if	
> > > > 2016-08-06 21:26:43.295774282 +0200
> > > > +++ refpolicy-git-06082016/policy/modules/services/xserver.if	
> > > > 2016-08-19 15:52:41.712830041 +0200
> > > > @@ -163,6 +163,8 @@ interface(`xserver_role',`
> > > > ?	relabel_dirs_pattern($2, user_fonts_config_t,
> > > > user_fonts_config_t)
> > > > ?	relabel_files_pattern($2, user_fonts_config_t,
> > > > user_fonts_config_t)
> > > > 
> > > > +	# for the accelerated graphic drivers
> > > > +	dev_rw_dri($2)
> > > > ?')
> > > > 
> > > > ?#######################################
> > > 
> > > I'm fine with this change, but I think it should be
> > > conditional.??Then
> > > people that don't want users to have direct access to hardware,
> > > like
> > > this, can disable it.
> > 
> > What's the point ? DRI can already be disabled in the X server
> > configuration file easily and using it should not pose a security
> > risk.
> > 
> > So, why increasing the complexity for little or no gain ?
> 
> In this case, it has little to do with the X server.??$2 is a user?
> domain, so you're saying any app the user can run (in the user's
> domain)?
> can rw the DRI device.

That is badly wrong.

I understand the issue now !

Perhaps, we can target the application that generated such permission
request (from Gnome), confine it in its own domain and then grant the
permission only for that domain...

--
Guido

[refpolicy] [PATCH] xserver: add r/w permissions for the DRI devices

[Dominick Grift]

On 08/24/2016 01:11 AM, Guido Trentalancia via refpolicy wrote:
> Hello Christopher.
> 
> On Tue, 23/08/2016 at 18.53 -0400, Chris PeBenito wrote:
>> On 08/23/16 09:21, Guido Trentalancia wrote:
>>>
>>> On Mon, 22/08/2016 at 20.52 -0400, Chris PeBenito wrote:
>>>>
>>>> On 08/20/16 10:52, Guido Trentalancia wrote:
>>>>>
>>>>>
>>>>> Modify the xserver role, so that the Direct Rendering
>>>>> Infrastructure
>>>>> devices can be opened read/write (used for graphic
>>>>> acceleration,
>>>>> for example, by Mesa/libGL).
>>>>>
>>>>> Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
>>>>> ---
>>>>>  policy/modules/services/xserver.if |    2 ++
>>>>>  1 file changed, 2 insertions(+)
>>>>>
>>>>> --- refpolicy-git-06082016-
>>>>> orig/policy/modules/services/xserver.if	
>>>>> 2016-08-06 21:26:43.295774282 +0200
>>>>> +++ refpolicy-git-06082016/policy/modules/services/xserver.if	
>>>>> 2016-08-19 15:52:41.712830041 +0200
>>>>> @@ -163,6 +163,8 @@ interface(`xserver_role',`
>>>>>  	relabel_dirs_pattern($2, user_fonts_config_t,
>>>>> user_fonts_config_t)
>>>>>  	relabel_files_pattern($2, user_fonts_config_t,
>>>>> user_fonts_config_t)
>>>>>
>>>>> +	# for the accelerated graphic drivers
>>>>> +	dev_rw_dri($2)
>>>>>  ')
>>>>>
>>>>>  #######################################
>>>>
>>>> I'm fine with this change, but I think it should be
>>>> conditional.  Then
>>>> people that don't want users to have direct access to hardware,
>>>> like
>>>> this, can disable it.
>>>
>>> What's the point ? DRI can already be disabled in the X server
>>> configuration file easily and using it should not pose a security
>>> risk.
>>>
>>> So, why increasing the complexity for little or no gain ?
>>
>> In this case, it has little to do with the X server.  $2 is a user 
>> domain, so you're saying any app the user can run (in the user's
>> domain) 
>> can rw the DRI device.
> 
> That is badly wrong.
> 
> I understand the issue now !
> 
> Perhaps, we can target the application that generated such permission
> request (from Gnome), confine it in its own domain and then grant the
> permission only for that domain...
> 

My personal DSSP policy does exactly that. It enforces LP consistently
by design. Anything that is not targeted is at risk of being
dis-functional. simply because the login shell domain has relatively
little permissions, and so only common core utilities will be functional
in that domain.

The idea is that pretty much every process that is used has to be
targeted. You can imagine how big the policy would get over time.

Therefore with DSSP, profiling is very important. Only policy that is
used should be installed/loaded, and only code that is used should be
installed/run.

This is, in my view, the only way to provide a base that works for
everyone. Because it is easier to add some new permissions than to
remove existing ones.

Ofcourse this approach will not work for everyone, but this approach is
what defines DSSP's security model.

It makes things simpler.

> --
> Guido
> _______________________________________________
> 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/20160824/1bd3ecab/attachment.bin