Gentoo Archives: gentoo-hardened

From: Sven Vermeulen <swift@g.o>
To: gentoo-hardened@l.g.o
Subject: [gentoo-hardened] SELinux base policy rev 14 in hardened-dev
Date: Tue, 10 Jul 2012 21:02:30
Message-Id: 20120710191436.GA30687@gentoo.org
1 Hi golks,
2
3 Revision 14 of the SELinux policies is now in hardened-dev overlay. I will,
4 from now on, bump all SELinux ebuilds as that seems to be necessary to
5 support changes in the policies (well, not always, but the moment an
6 interface is updated that is called by many/all modules, it is not
7 sufficient to just reload them, you need to rebuild them).
8
9 Luckily, it seems that Portage is working out some support for these cases
10 and I *think* I can have all ebuilds depend on selinux-base-policy with that
11 SLOT-abi-stuff that has been on the mailinglist a while back. That might
12 automatically rebuild the packages, and as such removes the need to bump all
13 other module packages.
14
15 That being said, this revision includes the following changes:
16
17 #410961 Get the descriptions for booleans properly displayed
18 <no bug> Backport nss_domain attribute patch
19 <no bug> Backport blueman policy
20 <no bug> Backport bcfg2 policy
21 #424359 Allow udev init script to generate correct labels on data &
22 rules.d (/run/udev)
23 <no bug> Backport support/ related commits
24 <no bug> Backport packagekit file contexts
25 <no bug> Refactor dracut domain policy
26 <no bug> Refactor fixes for udev and init support for /run directory
27
28 Bug #424359 especially is important for the users that noticed their Xorg
29 not accepting keyboard commands (or even mouse input, although I couldn't
30 reproduce it for mice). A quick fix with earlier policies is to "restorecon
31 -Rv /run" but this policy update makes it that this isn't necessary anymore.
32
33 There is another tracker still open (#424173) which I'll use to track other
34 bugs related to the introduction of /run. However, for those wondering - I
35 can't handle the comment in the tracker itself, there is too much cruft in
36 it. Bugreports for the SELinux policy should be quite isolated so that
37 updates can be made in a progressive approach. This is needed if we want to
38 still keep pushing our changes upstream.
39
40 Speaking of upstream, I *might* switch from the refpolicy builds to our own
41 policy builds. I'm seriously considering adding more comments to our
42 policies to make it easier to support in the future, as well as enhance the
43 documentation from it. But that means the patches are less likely to get
44 accepted as-is by the reference policy. That's however not really a problem,
45 since I've been manually moving changes upstream anyhow.
46
47 Using our own builds also makes the deployment faster, since we're currently
48 already at 118 patch sets (for a total of 186 patches) of which 36 patchsets
49 have been accepted upstream, 8 are waiting submission, 61 have not been sent
50 out (either because they don't match the coding style or need refinement)
51 and 4 are not going to be sent out (as they don't match the reference
52 policy's focus).
53
54 The reason I'm not doing it immediately is because I want to make sure, for
55 myself, that I can keep on pushing our changes upstream, helping the rest of
56 the SELinux community with our updates. That's also the only change, since
57 backporting changes from refpolicy to our tree is fairly easy (as you can
58 see from rev 14, many backports) so we stay on track (and up2date).
59
60 That being said, please give revision 14 a go. I'm going to push it to the
61 main tree in a couple of days and am considering fast-moving this to stable
62 (not wait the usual 30 days) since the current stable doesn't play well with
63 the /run changes (of which rev12, 13 and 14 contain very important patches
64 for).
65
66 Wkr,
67 Sven Vermeulen