From: dac.override@gmail.com (Dominick Grift) Date: Tue, 23 Aug 2016 15:45:29 +0200 Subject: [refpolicy] [PATCH] xserver: add r/w permissions for the DRI devices In-Reply-To: <3FB9719D-1DD2-4B1F-903E-0A0E2FB85001@trentalancia.net> References: <1471704751.17584.8.camel@trentalancia.net> <1471958481.9254.2.camel@trentalancia.net> <021b4bee-b488-c61c-2bae-dfe1e78e5a77@gmail.com> <3FB9719D-1DD2-4B1F-903E-0A0E2FB85001@trentalancia.net> Message-ID: <48d16b24-68b2-6f12-cbb4-09414028d828@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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 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 >>>>> --- >>>>> 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