1 |
Hi Chris & hardened development, |
2 |
|
3 |
The ebuilds within the hardened-dev overlay for the SELinux policies are |
4 |
currently fully based upon the reference policy as released by Tresys. The |
5 |
changes made beyond the reference policy are currently added as patches in the |
6 |
files/ folder. However, as things progress, the number of patches is increasing |
7 |
and will soon hit the 20k limit that Gentoo (and the QA team) sets for files |
8 |
inside the files/ folder. |
9 |
|
10 |
Of course, the main idea is that we feed back those changes towards the |
11 |
reference policy development itself (which is gradually done) but this will take |
12 |
time and will not remove this situation. |
13 |
|
14 |
A few solutions are possible: |
15 |
|
16 |
- Put the patches as separate downloads (SRC_URI in the ebuild), in which case |
17 |
we will need to combine the patches in "less frequent" releases. This is |
18 |
entirely plausible and used by other ebuilds as well. It also allows for some |
19 |
package stability (the patchbundle in SRC_URI is the master, subpatching is |
20 |
still possible through the files/ folder) |
21 |
|
22 |
- Create intermediate releases based on our own repository of the policies and |
23 |
modules (like Fedora and other distributions do). This makes development |
24 |
easier, but maintenance becomes more difficult: you'll need to perform quality |
25 |
testing before we can create ebuilds (or use snapshots and from time to time |
26 |
stabilize a snapshot) and staying close with the reference policy itself might |
27 |
be more challenging (although I've heard great things of git being able to do |
28 |
such mergers, but have no experience with that myself) |
29 |
|
30 |
- Instead of patching existing modules, we can also create modules that |
31 |
introduce the "patches" themselves. After all, most (if not all) patches are |
32 |
about allowing more things or declaring more types/domains rather than |
33 |
dismissing privileges that have been granted. |
34 |
|
35 |
The biggest patch user remains the selinux-base-policy ebuild as this needs to |
36 |
be patched every time. Until now, I have not seen any other ebuild which might |
37 |
get too many patches. |
38 |
|
39 |
Why selinux-base-policy? Well, this one needs to be patched every time |
40 |
|
41 |
- an interface is added to some domain (regardless if the user is using that |
42 |
domain or not) as only the base policy manages the include files in |
43 |
/usr/share/selinux/strict/include (or targeted/include). |
44 |
- an additional module is added as this means that the regular roles and domains |
45 |
(user_t, staff_t and sysadm_t + affiliated roles) need to be 'enhanced' with |
46 |
support for these modules (new module for gorg -> gorg_role interface needs to |
47 |
be defined and used by the various users) |
48 |
|
49 |
I don't know what you guys think? Chris, you especially ;-) My personal |
50 |
preference goes to the patches themselves so that we do not drift away from the |
51 |
reference policy and are forced to keep track of it. Also, when a new release is |
52 |
made, we can look at the individual patches to see which still need to be |
53 |
included and which not. |
54 |
|
55 |
Wkr, |
56 |
Sven Vermeulen |