| 1 |
Hi guys 'n gals, |
| 2 |
|
| 3 |
Like I suggested in the "SELinux and no-multilib" thread [1], I would like |
| 4 |
to take a stab at the SELinux Gentoo profiles to make them easy to manage |
| 5 |
(and to get that weird (no)multilib thing back on track). As the thread |
| 6 |
said, I am focussing on creating a "features/selinux" profile which, like |
| 7 |
the "features/multilib" or "features/no-nptl" ones, cannot be used |
| 8 |
directly but is used by a parent file within a profile. |
| 9 |
|
| 10 |
When a good "features/selinux" profile is created, we can then create |
| 11 |
hardened/linux/amd64/selinux |
| 12 |
hardened/linux/amd64/no-multilib/selinux |
| 13 |
hardened/linux/x86/selinux |
| 14 |
... |
| 15 |
profiles in which only a single file exists, namely "parent", with the |
| 16 |
contents of |
| 17 |
../ |
| 18 |
../../../../features/selinux |
| 19 |
|
| 20 |
To verify that this is indeed possible, I've already started with a |
| 21 |
"features/selinux" profile on my own overlay [2] and am currently testing |
| 22 |
it (both a "hardened/linux/amd64/selinux" and ..."amd64/no-multilib/selinux" |
| 23 |
guest) to see if they generate any issues. |
| 24 |
|
| 25 |
Until now, I have not found any issue. What I do find is that the |
| 26 |
hardened/linux/amd64/* ones are more aligned with the hardened profiles |
| 27 |
than the selinux/v2refpolicy/amd64/hardened profile (current |
| 28 |
production-use profile) with respect to USE changes and such. |
| 29 |
|
| 30 |
In my opinion, this method has many advantages: |
| 31 |
- the selinux profiles are close to their master profile (and as such |
| 32 |
inherit the updates and management of those profiles) |
| 33 |
- the new profiles can be used simultaneously with the old ones, allowing |
| 34 |
for a transition period |
| 35 |
- the SELinux specific changes are tied in a single location, making |
| 36 |
administration a bit more easy (and we're all for easy, aren't we?) |
| 37 |
- if new profiles would like to support a selinux-specific one as well, it |
| 38 |
is far easier with a "features/selinux" approach than it is with the |
| 39 |
current selinux/v2refpolicy/* I think |
| 40 |
|
| 41 |
Now my question(s): |
| 42 |
- Does anyone know of a problem with this approach? |
| 43 |
- Does anyone have any objections if I (or someone else) puts this |
| 44 |
information in hardened-dev.git (blueness, you did last profile updates |
| 45 |
with a staging in hardened-dev.git, but in a separate branch [3], do you |
| 46 |
think this approach is needed here as well or can this be put in the |
| 47 |
master)? |
| 48 |
- And if people have objections, any other ideas on how to tackle the |
| 49 |
problem that current SELinux profiles do not support no-multilib (but do |
| 50 |
not enable "multilib" USE flag) [4]? |
| 51 |
|
| 52 |
Wkr, |
| 53 |
Sven Vermeulen |
| 54 |
|
| 55 |
[1] http://thread.gmane.org/gmane.linux.gentoo.hardened/4820/focus=4824 |
| 56 |
[2] https://github.com/sjvermeu/gentoo.overlay/tree/master/profiles |
| 57 |
[3] https://bugs.gentoo.org/show_bug.cgi?id=344861 |
| 58 |
[4] https://bugs.gentoo.org/show_bug.cgi?id=298434 and |
| 59 |
https://bugs.gentoo.org/show_bug.cgi?id=346563 |
Archives