Re: [RFC][PATCH v2] selinux: support deferred mapping of contexts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2008-05-02 at 11:47 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stephen Smalley wrote:
> > On Thu, 2008-05-01 at 23:22 +1000, James Morris wrote:
> >> On Thu, 1 May 2008, Stephen Smalley wrote:
> >>
> >>> the build host with no way to define it).  Or a mechanism for a
> >>> hierarchy of policies (complex, and not clear how to handle objects as
> >>> they may be visible to processes operating under more than one policy,
> >>> e.g. both inside and outside of the chroot).
> >> Indeed, this might be helped by encoding DOIs into labels but would likely 
> >> add lots of complexity and performance overhead.  AFAICT, entities in 
> >> different policy namespaces would need to be totally separated (unless 
> >> purely hierarchical).
> > 
> > Pure isolation would be cleaner, but won't work in the buildsys example,
> > as there we have rpm (running outside the chroot) installing files into
> > the chroot tree and then launching scriptlets within the chroot, so we
> > have processes both outside and within the chroot acting on the files.
> > 
> > In any event, of the available alternatives, I think the
> > set-unknown-label option may be the only practical one. So if you have
> > any comments on the code in the patch or if you want it split into two
> > stages, let me know.  Otherwise, I'll re-spin it with Casey's suggested
> > change.
> > 
> This is half the solution.  Don't we need a new /selinux for inside the
> chroot, so that when selinux-policy rpm installs the policy, it lies and
> says the policy was loaded.  Then at the end of the install , restorecon
> is running on the entire image to make sure the labels match the
> file_context in the chroot.

I don't know offhand, but that is something the installer folks can do
on their own.  Just make a fake /selinux directory in the chroot with
"load" as a hard link to /dev/null?

I do expect we'll run into other issues, but we won't really know what
they all are until we try using this kernel patch first.  Can we get the
patch (w/ Casey's suggested change) put into a Fedora kernel for initial
testing before upstreaming?

-- 
Stephen Smalley
National Security Agency


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

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux