1 |
On 01/08/2011 07:45 AM, Sven Vermeulen wrote: |
2 |
> Hi Chris& hardened development, |
3 |
> |
4 |
> The ebuilds within the hardened-dev overlay for the SELinux policies are |
5 |
> currently fully based upon the reference policy as released by Tresys. The |
6 |
> changes made beyond the reference policy are currently added as patches in the |
7 |
> files/ folder. However, as things progress, the number of patches is increasing |
8 |
> and will soon hit the 20k limit that Gentoo (and the QA team) sets for files |
9 |
> inside the files/ folder. |
10 |
> |
11 |
> Of course, the main idea is that we feed back those changes towards the |
12 |
> reference policy development itself (which is gradually done) but this will take |
13 |
> time and will not remove this situation. |
14 |
> |
15 |
> A few solutions are possible: |
16 |
> |
17 |
> - Put the patches as separate downloads (SRC_URI in the ebuild), in which case |
18 |
> we will need to combine the patches in "less frequent" releases. This is |
19 |
> entirely plausible and used by other ebuilds as well. It also allows for some |
20 |
> package stability (the patchbundle in SRC_URI is the master, subpatching is |
21 |
> still possible through the files/ folder) |
22 |
> |
23 |
I personally favor this approach. It allows us to stay close to the |
24 |
refpolicy, and should also help in making it easier to track when |
25 |
something in refpolicy obviates the need for a particular patch. |
26 |
> - Create intermediate releases based on our own repository of the policies and |
27 |
> modules (like Fedora and other distributions do). This makes development |
28 |
> easier, but maintenance becomes more difficult: you'll need to perform quality |
29 |
> testing before we can create ebuilds (or use snapshots and from time to time |
30 |
> stabilize a snapshot) and staying close with the reference policy itself might |
31 |
> be more challenging (although I've heard great things of git being able to do |
32 |
> such mergers, but have no experience with that myself) |
33 |
> |
34 |
I do this in my private git repo. merging with git can sometimes be a |
35 |
bit challenging, but then I'm not well versed in git either. The |
36 |
concern about quality testing before we create ebuilds is, I think, a |
37 |
wash. We need to do that regardless of our approach. After all, a bad |
38 |
patch is still a pretty serious problem. IMO, this option is best kept |
39 |
for private repos. |
40 |
> - Instead of patching existing modules, we can also create modules that |
41 |
> introduce the "patches" themselves. After all, most (if not all) patches are |
42 |
> about allowing more things or declaring more types/domains rather than |
43 |
> dismissing privileges that have been granted. |
44 |
> |
45 |
This is neat and sexy, but can potentially create a situation where we |
46 |
have loads of packages coming and going as we change patch sets, plus |
47 |
the user not being able to have a reasonably good idea of what packages |
48 |
are pulled in as deps. Not to mention the whole issue of changing |
49 |
deps. And if we make a single package called selinux-patches or |
50 |
something similar, then we are really back to the first option. Or am I |
51 |
misunderstanding? |
52 |
> The biggest patch user remains the selinux-base-policy ebuild as this needs to |
53 |
> be patched every time. Until now, I have not seen any other ebuild which might |
54 |
> get too many patches. |
55 |
> |
56 |
> Why selinux-base-policy? Well, this one needs to be patched every time |
57 |
> |
58 |
> - an interface is added to some domain (regardless if the user is using that |
59 |
> domain or not) as only the base policy manages the include files in |
60 |
> /usr/share/selinux/strict/include (or targeted/include). |
61 |
> - an additional module is added as this means that the regular roles and domains |
62 |
> (user_t, staff_t and sysadm_t + affiliated roles) need to be 'enhanced' with |
63 |
> support for these modules (new module for gorg -> gorg_role interface needs to |
64 |
> be defined and used by the various users) |
65 |
> |
66 |
Every selinux-* package has an in-built dependency on |
67 |
selinux-base-policy anway, so I don't really see this as a problem. |
68 |
> I don't know what you guys think? Chris, you especially ;-) My personal |
69 |
> preference goes to the patches themselves so that we do not drift away from the |
70 |
> reference policy and are forced to keep track of it. Also, when a new release is |
71 |
> made, we can look at the individual patches to see which still need to be |
72 |
> included and which not. |
73 |
> |
74 |
> Wkr, |
75 |
> Sven Vermeulen |