Gentoo Archives: gentoo-hardened

From: Jason Zaman <perfinion@g.o>
To: gentoo-hardened@l.g.o
Subject: Re: [gentoo-hardened] SELinux: Granting kernel_t (kdevtmpfs) manage rights on /dev/*
Date: Thu, 05 Mar 2015 05:34:26
Message-Id: 20150305053354.GA20209@meriadoc.perfinion.com
In Reply to: Re: [gentoo-hardened] SELinux: Granting kernel_t (kdevtmpfs) manage rights on /dev/* by Luis Ressel
1 On Wed, Mar 04, 2015 at 11:04:34PM +0100, Luis Ressel wrote:
2 > On Wed, 4 Mar 2015 20:21:08 +0000
3 > Sven Vermeulen <swift@g.o> wrote:
4 >
5 > > 1. I can temporarily ignore the issue, perhaps hiding the cosmetic
6 > > denial behind dontaudit statements
7 > > 2. I can restrictively add to kernel_t those rules that do not
8 > > trigger the neverallow rules and ignore/dontaudit the rest
9 > > 3. I can break isolation a bit and explicitly add kernel_t to the
10 > > neverallow rule exemption
11 > > 4. I can move the necessary attributes and statements into the devices
12 > > module (which is part of the base)
13 > > 5. I can move forward with the storage-becomes-base approach
14 >
15 > I've been allowing this in my local policy since 2013. I'm sure it was
16 > neccessary for something to work, however I don't recall what for. But
17 > that means 1. is not really an option.
18 >
19 > For now, I'd just wait for more feedback on the refpolicy ML. This is
20 > not an urgent problem, so I'd prefer not to diverge further from
21 > upstream if we can avoid it.
22
23 I also think we should deviate as little as possible from upstream.
24 >
25 > 5. seems to be the cleanest solution, but I've got to dig around a bit
26 > in the refpolicy to estimate the amount of work it'd require.
27 >
28 > If we want a temporary fix, I'd go with 3. It's only a tiny change, so
29 > it wouldn't cause too much confusing upstream divergence.
30
31 I dont think this is a very high priority issue so we can probably
32 upstream it first and then fix it in gentoo. Storage becoming base
33 makes sense since storage is pretty important. The patch in the email
34 seemed reasonable. although i think we'd also need to add to the eclass
35 that when inserting a new module it will check priority 100 and remove
36 it after inserting the new module.
37
38 -- Jason