Re: Fedora buildsys and SELinux
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 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.
But unfortunately we weren't able to sort the remaining issues
discussed
in that thread.
> Also, I wanted to emphasize that chroot is different than unsharing the
> filesystem namespace, and per-chroot policy is not the same thing as
> per-namespace policy. I'd expect though that it would actually be a
> per-process policy mechanism, with most processes sharing the same
> policy but programs like rpm being able to unshare policy from their
> parent and then load a private policy to be applied only to their
> descendants.
>
--
Stephen Smalley
National Security Agency