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.
Note for anyone trying to revive that patch: please be sure to
introduce a new security class for that permission instead of adding it
to the security class as I did in that patch, so that we can be certain
that this new ability won't be allowed to unconfined domains by default.
We do not want unconfined_t user shells to be able to set arbitrary
label values w/o no warning that it wasn't valid; we want to limit this
to specific programs like rpm that will be aware of the implications and
(hopefully) do some validity checking of their own afterward.
National Security Agency