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 |