* [gentoo-hardened] SELinux Gentoo profiles (the /usr/portage/profiles kind)
@ 2011-04-27 19:46 Sven Vermeulen
2011-04-27 20:24 ` Chris Richards
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Sven Vermeulen @ 2011-04-27 19:46 UTC (permalink / raw
To: gentoo-hardened
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-hardened] SELinux Gentoo profiles (the /usr/portage/profiles kind)
2011-04-27 19:46 [gentoo-hardened] SELinux Gentoo profiles (the /usr/portage/profiles kind) Sven Vermeulen
@ 2011-04-27 20:24 ` Chris Richards
2011-04-28 12:09 ` Anthony G. Basile
2011-04-28 12:08 ` Anthony G. Basile
2011-04-29 11:19 ` Anthony G. Basile
2 siblings, 1 reply; 6+ messages in thread
From: Chris Richards @ 2011-04-27 20:24 UTC (permalink / raw
To: gentoo-hardened
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
>
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-hardened] SELinux Gentoo profiles (the /usr/portage/profiles kind)
2011-04-27 19:46 [gentoo-hardened] SELinux Gentoo profiles (the /usr/portage/profiles kind) Sven Vermeulen
2011-04-27 20:24 ` Chris Richards
@ 2011-04-28 12:08 ` Anthony G. Basile
2011-04-29 11:19 ` Anthony G. Basile
2 siblings, 0 replies; 6+ messages in thread
From: Anthony G. Basile @ 2011-04-28 12:08 UTC (permalink / raw
To: gentoo-hardened
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-hardened] SELinux Gentoo profiles (the /usr/portage/profiles kind)
2011-04-27 20:24 ` Chris Richards
@ 2011-04-28 12:09 ` Anthony G. Basile
0 siblings, 0 replies; 6+ messages in thread
From: Anthony G. Basile @ 2011-04-28 12:09 UTC (permalink / raw
To: gentoo-hardened
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-hardened] SELinux Gentoo profiles (the /usr/portage/profiles kind)
2011-04-27 19:46 [gentoo-hardened] SELinux Gentoo profiles (the /usr/portage/profiles kind) Sven Vermeulen
2011-04-27 20:24 ` Chris Richards
2011-04-28 12:08 ` Anthony G. Basile
@ 2011-04-29 11:19 ` Anthony G. Basile
2011-05-02 12:03 ` Anthony G. Basile
2 siblings, 1 reply; 6+ messages in thread
From: Anthony G. Basile @ 2011-04-29 11:19 UTC (permalink / raw
To: gentoo-hardened
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-hardened] SELinux Gentoo profiles (the /usr/portage/profiles kind)
2011-04-29 11:19 ` Anthony G. Basile
@ 2011-05-02 12:03 ` Anthony G. Basile
0 siblings, 0 replies; 6+ messages in thread
From: Anthony G. Basile @ 2011-05-02 12:03 UTC (permalink / raw
To: gentoo-hardened
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-05-02 13:02 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-04-27 19:46 [gentoo-hardened] SELinux Gentoo profiles (the /usr/portage/profiles kind) Sven Vermeulen
2011-04-27 20:24 ` Chris Richards
2011-04-28 12:09 ` Anthony G. Basile
2011-04-28 12:08 ` Anthony G. Basile
2011-04-29 11:19 ` Anthony G. Basile
2011-05-02 12:03 ` Anthony G. Basile
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox