Gentoo Archives: gentoo-hardened

From: Sven Vermeulen <sven.vermeulen@××××××.be>
To: gentoo-hardened@l.g.o
Subject: [gentoo-hardened] SELinux ebuilds and patches
Date: Sat, 08 Jan 2011 14:10:24
Message-Id: 20110108134552.GA11521@siphos.be
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

Replies

Subject Author
Re: [gentoo-hardened] SELinux ebuilds and patches Chris Richards <gizmo@×××××××××.com>