Fedora buildsys and SELinux

[Eric Paris]

On Mon, 2008-05-05 at 09:35 -0400, Stephen Smalley wrote:
> On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote:
> > On Tue, 2008-04-22 at 12:38 -0400, Stephen Smalley wrote:
> > > On Tue, 2008-04-22 at 11:55 -0400, Stephen Smalley wrote:
> > > > On Thu, 2008-04-17 at 09:12 -0400, Stephen Smalley wrote:
> > > > > On Wed, 2008-04-16 at 23:23 -0400, Bill Nottingham wrote:
> > > > > > James Morris (jmorris at namei.org) said: 
> > > > > > > > You cannot create files in a chroot of a context not known by the
> > > > > > > > host policy. This means that if your host is running RHEL 5, you are
> > > > > > > > unable to compose any trees/images/livecds with SELinux enabled for
> > > > > > > > later releases.
> > > > > > > 
> > > > > > > Ok, that's what I suspected.
> > > > > > > 
> > > > > > > One of the possible plans for this is to allow a process to run in a 
> > > > > > > separate policy namespace, and probably also utilize namespace support in 
> > > > > > > general.
> > > > > > > 
> > > > > > > This is non-trivial and needs more analysis.
> > > > > > 
> > > > > > Incidentally, this is also one of the blockers for policy-in-packages,
> > > > > > rather than a monolithic one.
> > > > > 
> > > > > I assume you mean setting down unknown file labels rather than
> > > > > per-namespace or per-chroot policy support.  I think they are related
> > > > > but different.  The former is required if you always plan to install the
> > > > > files _before_ loading the policy.  The latter is required primarily for
> > > > > getting any scriptlets to run in the right security contexts so that any
> > > > > files they create are labeled appropriately within the chroot.
> > > > 
> > > > BTW, for reference, a patch to support setting down unknown file labels
> > > > was posted here a couple of years ago:
> > > > http://marc.info/?l=selinux&m=114771094617968&w=2
> > > 
> > > And the last version of that patch was:
> > > http://marc.info/?l=selinux&m=114840466518263&w=2
> > > Not that it applies cleanly anymore, of course.
> > 
> > An updated patch and discussion has started over on selinux list, see:
> > http://marc.info/?t=120958955400002&r=1&w=2
> > 
> > One question that has come up is whether the patch to support setting
> > unknown file labels is sufficient to support the buildsys needs, or
> > whether something more is required.  My impression is that all we truly
> > need is:
> > 1) support for setting unknown file labels for use by rpm, and
> > 2) bind mount /dev/null over selinux/load within the chroot so that
> > policy loads within the chroot do nothing rather than changing the build
> > host's policy, and
> > 3) bind mount a regular empty file over selinux/context within the
> > chroot so that attempts to validate/canonicalize contexts by rpm will
> > always return the original value w/o trying to validate against the
> > build host's policy.
> 
> We need to better understand the sequence of actions performed by rpm,
> both from outside the chroot and from within the chroot, to know
> precisely what is needed here.
> 
> It would be cleaner if we could just disable policy reload altogether.
> libsemanage will skip policy reload if:
> 1) the caller asked to skip reload (e.g. semodule with the -n option) or
> 2) the caller asked to operate on a policy store other than the active
> policy store (e.g. semodule with the -s option), or
> 3) SELinux appears to be disabled.
> 
> We can fake the last one, but I think that will confuse rpm with respect
> to other actions we still want it to take, like labeling the files,
> transitioning to a scriptlet domain, etc.

In this case is scriptlet transition really important?  What is to be
gained?  Its not like we are getting file transitions...

> 
> On the context validation/canonicalization, it would be cleaner if we
> could have rpm validate and canonicalize against the target image's
> policy rather than the build host's policy.  This is likely doable, as
> setfiles has to do something like this for its -c option when validating
> a file contexts configuration against a policy at policy build time.
> Requires calling a libselinux interface to register an alternative
> validate callback.

This sounds like a great idea, but is clearly going to take work from
the RPM people....