From: dac.override@gmail.com (Dominick Grift) Date: Wed, 24 Aug 2016 12:32:18 +0200 Subject: [refpolicy] [PATCH] xserver: add r/w permissions for the DRI devices In-Reply-To: <1471993888.12192.7.camel@trentalancia.net> References: <1471704751.17584.8.camel@trentalancia.net> <1471958481.9254.2.camel@trentalancia.net> <36091975-d0d4-0705-3052-3d9658acde4b@ieee.org> <1471993888.12192.7.camel@trentalancia.net> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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 >>>>> --- >>>>> 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