Re: [gentoo-hardened] SELinux Gentoo profiles (the /usr/portage/profiles kind)

[Chris Richards]

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
>
>
>