public inbox for gentoo-hardened@lists.gentoo.org
 help / color / mirror / Atom feed
* [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
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