From: aranea@aixah.de (Luis Ressel)
Date: Tue, 19 Sep 2017 20:36:55 +0200
Subject: [refpolicy] Do we need a new domain for
 /usr/share/misc/magic.mgc?
In-Reply-To: <20170919163822.GA24469@julius.enp8s0.d30>
References: <20170919164021.19528-1-aranea@aixah.de>
	<20170919163822.GA24469@julius.enp8s0.d30>
Message-ID: <20170919203655.7b2757c2@vega.skynet.aixah.de>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Tue, 19 Sep 2017 18:38:22 +0200
Dominick Grift via refpolicy <refpolicy@oss.tresys.com> wrote:

> On Tue, Sep 19, 2017 at 06:40:20PM +0200, Luis Ressel via refpolicy
> wrote:
> > Hello,
> > 
> > libmagic (better known by its CLI frontend 'file') needs to mmap()
> > its signature database, which is currently labeled usr_t. If any of
> > refpolicy's application domains need to call 'file' (or use
> > libmagic) directly, we may want to create a new domain for this
> > signature db so that the map permission can be granted only on this
> > domain instead of the much bigger usr_t.
> > 
> > However, the only domains I've found so far which need this access
> > are sysadm_t/staff_t/user_t and portage_t. The user domains already
> > have the neccessary permission, leaving only portage_t. Given that
> > portage_t can access *all* files in any case, I've decided to keep
> > the policy simple by just allowing it to map usr_t.
> > 
> > Is anyone aware of other file/libmagic users which would warrant the
> > creation of a new domain for the signature db?  
> 
> Stuff like icons probably also need to be mapped and are also usr_t,
> so i don't think that confining that by itself will solve all the
> issues

Yes, the GTK icon cache is also labeled usr_t and needs to be mappable.
However, compared to magic.mgc there are more domains which will need
this access, so I'm planning to create a new domain.

If I don't run into any problems, I'll submit a patch after dinner.

Cheers,
Luis Ressel