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(a)namei.org) said:
> > > > > You cannot create files in a chroot of a context not known by
> > > > > host policy. This means that if your host is running RHEL 5, you
> > > > > unable to compose any trees/images/livecds with SELinux enabled
> > > > > 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
> > > > 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:
And the last version of that patch was:
Not that it applies cleanly anymore, of course.
An updated patch and discussion has started over on selinux list, see:
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
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.
Plus the associated policy changes to permit the above to take place.
Does that sufficient?
The per-chroot/namespace policy idea sounds nice and elegant, but is a
lot more complicated, so if the above is workable, it provides a much
shorter term path for solving the buildsys problem.
National Security Agency