All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chad Sellers <csellers@tresys.com>
To: SE Linux <selinux@tycho.nsa.gov>
Cc: Joshua Brindle <jbrindle@tresys.com>,
	Steve Lawrence <slawrence@tresys.com>,
	Stephen Smalley <sds@tycho.nsa.gov>,
	Eamon Walsh <ewalsh@tycho.nsa.gov>
Subject: [RFC] Install SELinux policies from rpm package header
Date: Thu, 09 Jul 2009 11:03:05 -0400	[thread overview]
Message-ID: <C67B7EE9.A8979%csellers@tresys.com> (raw)

RPM currently has support for security policies to be stored in an rpm
header but it doesn't currently do anything with the policies. Instead,
SELinux policy is usually installed through %post scripts. We're planning to
work with the RPM community to get integrated support for SELinux policy,
and we'd like to get some feedback on our plans from the SELinux community.

First, a bit of background. SELinux policy is currently installed through
%post scripts. This presents several problems. First, this means that policy
for a given application may not be loaded at the time the files are written
to disk, preventing those files from being labeled properly, because the
symbols used to label files need to be in the policy loaded into the kernel.
Secondly, this means that if multiple packages install policy, each of their
%post scripts will reload the policy, which is a very expensive operation.
Consequently, policy is generally kept in a single package to avoid this,
despite containing many application specific policy modules that might be
more suited to be included in their application package. There are many
other problems with the current RPM support which I'd be happy to get into
as well, but I'll leave them out for now to prevent this email from getting
too long.

So, what we would like to do is to start including SELinux policy as part of
the rpm and have rpm install all policies together before files start to hit
the disk. To do this, we would like to use the already supported %policy
directive, which stores the policy in the RPM archive header.

We would then install the policy very early (before pretrans). This policy
load would involve gathering all the policies to be installed from all
packages, writing them to a temporary location, and calling out to semodule
to install the SELinux policy modules.

This new support will enable application packages to include their policy
within their package (e.g. bind includes the bind policy module in the bind
rpm), which would make it much easier to ensure that the appropriate policy
version is installed for a given application version. Note that while it is
possible to include policy within application packages, it is not necessary.
This new support would still allow a single policy RPM to contain many
policy modules as we have today. Those policy modules could then be slowly
split out to be included with the applications they confine as it makes
sense.

Obviously I'm glossing over many implementation details that would need to
be worked out. The point of this email is strictly to get feedback on our
approach. You can see a proof of concept patch that begins this
implementation, as well as some of our conversation with the RPM community
here:

http://lists.rpm.org/pipermail/rpm-maint/2009-July/002452.html

Thanks,
Chad Sellers


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

             reply	other threads:[~2009-07-09 15:03 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-09 15:03 Chad Sellers [this message]
2009-07-09 20:10 ` [RFC] Install SELinux policies from rpm package header Paul Howarth
2009-07-09 20:48   ` Daniel J Walsh
2009-07-09 21:13     ` Chad Sellers
2009-07-10 14:55       ` Joshua Brindle
2009-07-10 15:58         ` James Carter
2009-07-10 20:26           ` Joshua Brindle
2009-07-13 14:55             ` James Carter
2009-07-13 15:38               ` James Carter
2009-07-13 16:15             ` Chad Sellers
2009-07-13 17:33               ` Joe Nall
2009-07-13 17:40                 ` Joshua Brindle
2009-07-13 18:39                   ` Joe Nall
2009-07-13 18:52                     ` Joshua Brindle
2009-07-14 12:20                       ` Daniel J Walsh
2009-07-14 14:36                         ` Joshua Brindle
2009-07-10 21:11           ` max bianco
2009-07-13 20:42             ` Chad Sellers
2009-07-10 21:17       ` Paul Moore
2009-07-13 14:36         ` Joshua Brindle
2009-07-09 20:54   ` Chad Sellers

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=C67B7EE9.A8979%csellers@tresys.com \
    --to=csellers@tresys.com \
    --cc=ewalsh@tycho.nsa.gov \
    --cc=jbrindle@tresys.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    --cc=slawrence@tresys.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.