From: dac.override@gmail.com (Dominick Grift) Date: Tue, 23 Aug 2016 16:15:15 +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: <52c5efad-f8b1-60cd-c10a-0df32ee1ac54@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! 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 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/202cae8a/attachment.bin