On Mon, 2008-05-05 at 09:35 -0400, Stephen Smalley wrote: > On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote: > > 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@xxxxxxxxx) 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. > > > > An updated patch and discussion has started over on selinux list, see: > > http://marc.info/?t=120958955400002&r=1&w=2 > > > > 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 > > need is: > > 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. > > We need to better understand the sequence of actions performed by rpm, > both from outside the chroot and from within the chroot, to know > precisely what is needed here. > > It would be cleaner if we could just disable policy reload altogether. > libsemanage will skip policy reload if: > 1) the caller asked to skip reload (e.g. semodule with the -n option) or > 2) the caller asked to operate on a policy store other than the active > policy store (e.g. semodule with the -s option), or > 3) SELinux appears to be disabled. > > We can fake the last one, but I think that will confuse rpm with respect > to other actions we still want it to take, like labeling the files, > transitioning to a scriptlet domain, etc. In this case is scriptlet transition really important? What is to be gained? Its not like we are getting file transitions... > > On the context validation/canonicalization, it would be cleaner if we > could have rpm validate and canonicalize against the target image's > policy rather than the build host's policy. This is likely doable, as > setfiles has to do something like this for its -c option when validating > a file contexts configuration against a policy at policy build time. > Requires calling a libselinux interface to register an alternative > validate callback. This sounds like a great idea, but is clearly going to take work from the RPM people.... -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
