From: guido@trentalancia.net (Guido Trentalancia) Date: Tue, 23 Aug 2016 16:48:17 +0200 Subject: [refpolicy] [PATCH] xserver: add r/w permissions for the DRI devices In-Reply-To: <52c5efad-f8b1-60cd-c10a-0df32ee1ac54@gmail.com> 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> <52c5efad-f8b1-60cd-c10a-0df32ee1ac54@gmail.com> Message-ID: <1471963697.30659.19.camel@trentalancia.net> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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 > @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 > > > > > > --- > > > > > > ?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