On 04/27/2011 02:46 PM, Sven Vermeulen wrote:
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
In general, I like this idea. I've spoken with PeBenito, and he
indicates that the original design goal of the SELinux profiles was to
create a minimal working SELinux system, which one could then build off
of by customizing as necessary. However, this was all done prior to the
work that has since been done to make the default minimal profiles a bit
more rational. I <THINK> the base hardened and vanilla profiles are now
more in the line of being minimalist profiles which are then built on to
create the more full-featured profile sets, but someone who knows more
about this than me will have to comment.
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]?
I'm looking into writing a little tool that will help facilitate this,
giving us a 'profile explorer' that would enable use to see what a given
profile looks like without having to actually switch to it and then do
'emerge --info'. Kindof like a DOM explorer, but for Gentoo profiles.
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
