On Fri, 2008-05-02 at 12:14 -0400, Stephen Smalley wrote: > 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? Actually, why can't we just pretend selinux is disabled within the chroot (via a shared object that overrides is_selinux_enabled) to suppress attempts to reload policy into the kernel? Everything else (installing the policy files, running semanage, etc) is supposed to work even on a selinux-disabled host. As long as rpm itself knows that SELinux is enabled on the build host (which it should determine at startup before chroot'ing), I don't see the problem. > 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.
