Hi guys 'n gals,
Like I suggested in the "SELinux and no-multilib" thread [1], I would like
to take a stab at the SELinux Gentoo profiles to make them easy to manage
(and to get that weird (no)multilib thing back on track). As the thread
said, I am focussing on creating a "features/selinux" profile which, like
the "features/multilib" or "features/no-nptl" ones, cannot be used
directly but is used by a parent file within a profile.
When a good "features/selinux" profile is created, we can then create
hardened/linux/amd64/selinux
hardened/linux/amd64/no-multilib/selinux
hardened/linux/x86/selinux
...
profiles in which only a single file exists, namely "parent", with the
contents of
../
../../../../features/selinux
To verify that this is indeed possible, I've already started with a
"features/selinux" profile on my own overlay [2] and am currently testing
it (both a "hardened/linux/amd64/selinux" and ..."amd64/no-multilib/selinux"
guest) to see if they generate any issues.
Until now, I have not found any issue. What I do find is that the
hardened/linux/amd64/* ones are more aligned with the hardened profiles
than the selinux/v2refpolicy/amd64/hardened profile (current
production-use profile) with respect to USE changes and such.
In my opinion, this method has many advantages:
- the selinux profiles are close to their master profile (and as such
inherit the updates and management of those profiles)
- the new profiles can be used simultaneously with the old ones, allowing
for a transition period
- the SELinux specific changes are tied in a single location, making
administration a bit more easy (and we're all for easy, aren't we?)
- if new profiles would like to support a selinux-specific one as well, it
is far easier with a "features/selinux" approach than it is with the
current selinux/v2refpolicy/* I think
Now my question(s):
- Does anyone know of a problem with this approach?
- Does anyone have any objections if I (or someone else) puts this
information in hardened-dev.git (blueness, you did last profile updates
with a staging in hardened-dev.git, but in a separate branch [3], do you
think this approach is needed here as well or can this be put in the
master)?
- And if people have objections, any other ideas on how to tackle the
problem that current SELinux profiles do not support no-multilib (but do
not enable "multilib" USE flag) [4]?
Wkr,
Sven Vermeulen
[1] http://thread.gmane.org/gmane.linux.gentoo.hardened/4820/focus=4824
[2] https://github.com/sjvermeu/gentoo.overlay/tree/master/profiles
[3] https://bugs.gentoo.org/show_bug.cgi?id=344861
[4] https://bugs.gentoo.org/show_bug.cgi?id=298434 and
https://bugs.gentoo.org/show_bug.cgi?id=346563
