public inbox for gentoo-hardened@lists.gentoo.org
 help / color / mirror / Atom feed
From: Sven Vermeulen <sven.vermeulen@siphos.be>
To: gentoo-hardened@lists.gentoo.org
Subject: [gentoo-hardened] SELinux ebuilds and patches
Date: Sat, 8 Jan 2011 14:45:52 +0100	[thread overview]
Message-ID: <20110108134552.GA11521@siphos.be> (raw)

[-- Attachment #1: Type: text/plain, Size: 2933 bytes --]


Hi Chris & hardened development,

The ebuilds within the hardened-dev overlay for the SELinux policies are
currently fully based upon the reference policy as released by Tresys. The
changes made beyond the reference policy are currently added as patches in the
files/ folder. However, as things progress, the number of patches is increasing
and will soon hit the 20k limit that Gentoo (and the QA team) sets for files
inside the files/ folder.

Of course, the main idea is that we feed back those changes towards the
reference policy development itself (which is gradually done) but this will take
time and will not remove this situation.

A few solutions are possible:

- Put the patches as separate downloads (SRC_URI in the ebuild), in which case
  we will need to combine the patches in "less frequent" releases. This is
  entirely plausible and used by other ebuilds as well. It also allows for some
  package stability (the patchbundle in SRC_URI is the master, subpatching is
  still possible through the files/ folder)

- Create intermediate releases based on our own repository of the policies and
  modules (like Fedora and other distributions do). This makes development
  easier, but maintenance becomes more difficult: you'll need to perform quality
  testing before we can create ebuilds (or use snapshots and from time to time
  stabilize a snapshot) and staying close with the reference policy itself might
  be more challenging (although I've heard great things of git being able to do
  such mergers, but have no experience with that myself)

- Instead of patching existing modules, we can also create modules that
  introduce the "patches" themselves. After all, most (if not all) patches are
  about allowing more things or declaring more types/domains rather than
  dismissing privileges that have been granted.

The biggest patch user remains the selinux-base-policy ebuild as this needs to
be patched every time. Until now, I have not seen any other ebuild which might
get too many patches.

Why selinux-base-policy? Well, this one needs to be patched every time

- an interface is added to some domain (regardless if the user is using that
  domain or not) as only the base policy manages the include files in
  /usr/share/selinux/strict/include (or targeted/include).
- an additional module is added as this means that the regular roles and domains
  (user_t, staff_t and sysadm_t + affiliated roles) need to be 'enhanced' with
  support for these modules (new module for gorg -> gorg_role interface needs to
  be defined and used by the various users)

I don't know what you guys think? Chris, you especially ;-) My personal
preference goes to the patches themselves so that we do not drift away from the
reference policy and are forced to keep track of it. Also, when a new release is
made, we can look at the individual patches to see which still need to be
included and which not.

Wkr,
	Sven Vermeulen

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

             reply	other threads:[~2011-01-08 14:10 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-08 13:45 Sven Vermeulen [this message]
2011-01-09  5:10 ` [gentoo-hardened] SELinux ebuilds and patches Chris Richards

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110108134552.GA11521@siphos.be \
    --to=sven.vermeulen@siphos.be \
    --cc=gentoo-hardened@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox