FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Hardened

 
 
LinkBack Thread Tools
 
Old 04-27-2011, 07:46 PM
Sven Vermeulen
 
Default SELinux Gentoo profiles (the /usr/portage/profiles kind)

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
 
Old 04-27-2011, 08:24 PM
Chris Richards
 
Default SELinux Gentoo profiles (the /usr/portage/profiles kind)

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
 
Old 04-28-2011, 12:08 PM
"Anthony G. Basile"
 
Default SELinux Gentoo profiles (the /usr/portage/profiles kind)

On 04/27/2011 03:46 PM, Sven Vermeulen wrote:
> Hi guys 'n gals,
>

> 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

You mentioned this approach before and I like it because it is logically
clean. The idea is that you take any existing profile and you stack the
selinux feature on top of it --- thus "selinuxifying" that it.

The only issue I foresee is the typical profile problem, which is that
what packages/flags need to be masked/unmasked will depend on what you
stack selinux on top of, leading to conflicting requirements. This
gives rise to the profile silliness where the same package/use flag is
masked then unmasked then remasked etc as you move up through the stack,
with increasing customization on the last stacked item, thus making it
harder to maintain.

Having said that, I think selinux is less susceptible to this problem
than other so it may not be bad putting it at the end of the stacking
rather than closer to base.

The feature should probably be very minimal, dealing only with the
unmasking of sec-policy/* from base, masking of >=sec-policy/*-3, and
the critical selinux utilities in packages. You can drop a lot of the
minimum packages requirements in selinux/packages because 1) they're old
and 2) adding more such requirements just makes it harder to maintain.

I would not start with the tree. Stage it on the profiles branch of the
hardened-dev overlay, then mount --bind on top of profiles to test. You
may want to create a separate branch from the current profile branch.

Btw, the multilib no-multilib is a lot deeper problem. Here's the
stacking on hardened/linux/amd64/no-multilib. Its an example of the
mask/unmask/mask as you move up the stack problem:

/usr/portage/profiles/base
/usr/portage/profiles/default/linux
/usr/portage/profiles/arch/base
/usr/portage/profiles/features/multilib
/usr/portage/profiles/features/multilib/lib32
/usr/portage/profiles/arch/amd64
/usr/portage/profiles/releases
/usr/portage/profiles/releases/10.0
/usr/portage/profiles/hardened/linux
/usr/portage/profiles/hardened/linux/amd64
/usr/portage/profiles/features/64bit-native
/usr/portage/profiles/hardened/linux/amd64/no-multilib


So why does this stack include features/multilib??? There you have

use.force:multilib
use.mask:-multilib

which you later have to fix up in features/64bit-native where you have

use.force:-multilib
use.mask:multilib


What a mess!


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535
 
Old 04-28-2011, 12:09 PM
"Anthony G. Basile"
 
Default SELinux Gentoo profiles (the /usr/portage/profiles kind)

On 04/27/2011 04:24 PM, Chris Richards wrote:

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

#!/usr/bin/env python

import portage
for p in portage.settings.profiles:
print p


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535
 
Old 04-29-2011, 11:19 AM
"Anthony G. Basile"
 
Default SELinux Gentoo profiles (the /usr/portage/profiles kind)

On 04/27/2011 03:46 PM, Sven Vermeulen wrote:
> Hi guys 'n gals,
>
>
> 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
>

Hi Sven and all,

I got this structure set up on the hardened-dev overlay in branch
profiles-selinux. To use it, just mount --bind the overlay profile over
$PORTDIR/profiles.

Here's the stacking so far -- the reinheritance of base for amd64 is a
problem which I'll fix.

~ # eselect profile list
Available profile symlink targets:
[1] default/linux/amd64/10.0
[2] default/linux/amd64/10.0/desktop
[3] default/linux/amd64/10.0/desktop/gnome
[4] default/linux/amd64/10.0/desktop/kde
[5] default/linux/amd64/10.0/developer
[6] default/linux/amd64/10.0/no-multilib
[7] default/linux/amd64/10.0/server
[8] hardened/linux/amd64
[9] hardened/linux/amd64/selinux *
[10] hardened/linux/amd64/no-multilib
[11] hardened/linux/amd64/no-multilib/selinux

~ # ./check_profiles_stack.py
/usr/portage/profiles/base
/usr/portage/profiles/default/linux
/usr/portage/profiles/arch/base
/usr/portage/profiles/features/multilib
/usr/portage/profiles/features/multilib/lib32
/usr/portage/profiles/arch/amd64
/usr/portage/profiles/releases
/usr/portage/profiles/releases/10.0
/usr/portage/profiles/hardened/linux
/usr/portage/profiles/hardened/linux/amd64
/usr/portage/profiles/base
/usr/portage/profiles/features/selinux
/usr/portage/profiles/hardened/linux/amd64/selinux


~ # eselect profile set hardened/linux/amd64/no-multilib/selinux
~ # ./check_profiles_stack.py
/usr/portage/profiles/base
/usr/portage/profiles/default/linux
/usr/portage/profiles/arch/base
/usr/portage/profiles/features/multilib
/usr/portage/profiles/features/multilib/lib32
/usr/portage/profiles/arch/amd64
/usr/portage/profiles/releases
/usr/portage/profiles/releases/10.0
/usr/portage/profiles/hardened/linux
/usr/portage/profiles/hardened/linux/amd64
/usr/portage/profiles/features/64bit-native
/usr/portage/profiles/hardened/linux/amd64/no-multilib
/usr/portage/profiles/base
/usr/portage/profiles/features/selinux
/usr/portage/profiles/hardened/linux/amd64/no-multilib/selinux


yellowness ~ # ARCH="x86" eselect profile set hardened/linux/x86/selinux
yellowness ~ # ./check_profiles_stack.py
/usr/portage/profiles/base
/usr/portage/profiles/default/linux
/usr/portage/profiles/arch/base
/usr/portage/profiles/arch/x86
/usr/portage/profiles/releases
/usr/portage/profiles/releases/10.0
/usr/portage/profiles/hardened/linux
/usr/portage/profiles/hardened/linux/x86
/usr/portage/profiles/features
/usr/portage/profiles/hardened/linux/x86/selinux


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535
 
Old 05-02-2011, 12:03 PM
"Anthony G. Basile"
 
Default SELinux Gentoo profiles (the /usr/portage/profiles kind)

Hi guys,

1) I've opened up a tracker bug for switching to the new style profiles
for selinux:

http://bugs.gentoo.org/show_bug.cgi?id=365483

2) I've done some preliminary testing and it looks like they not only
work, but solve the amd64/nomultilib problem. I built such a system
with no problems.

3) The next step will be to add them to the tree side-by-side with the
existing selinux profiles. We can do this early, even within a week or
so since it will not break anything and will expose the new profile
structure to others for testing. I'll wait to hear back from the other
selinuxers before acting on this.

If anyone wants to test before they get to the tree, do the following

git clone git://git.overlays.gentoo.org/proj/hardened-dev.git
cd hardened-dev/
git branch profiles-selinux
git checkout profiles-selinux
git pull origin profiles-selinux
sudo mount --bin profiles/ /usr/portage/profiles/
sudo eselect profile list

You should now see

Available profile symlink targets:
[1] default/linux/amd64/10.0
[2] default/linux/amd64/10.0/desktop
[3] default/linux/amd64/10.0/desktop/gnome
[4] default/linux/amd64/10.0/desktop/kde
[5] default/linux/amd64/10.0/developer
[6] default/linux/amd64/10.0/no-multilib
[7] default/linux/amd64/10.0/server
[8] hardened/linux/amd64 *
[9] hardened/linux/amd64/selinux
[10] hardened/linux/amd64/no-multilib
[11] hardened/linux/amd64/no-multilib/selinux

sudo eselect profile set 9

or if you're using a no-multilib, try 11

emerge -uvpDN world

See what breaks/un-breaks. Report to the bug.


4) Long term. If we're happy, we deprecate the old profiles. This
includes sending out a news item explaining scheduling/procedure for
switch over etc etc.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535
 

Thread Tools




All times are GMT. The time now is 08:35 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org