On Mon, 2008-05-05 at 10:07 -0400, Eric Paris wrote: > 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... IIRC, failure to transition to rpm_script_t has caused problems in the past, either with denials or subsequent domain transitions or subsequent file transitions. If we could ensure that rpm and forked children prior to exec continue to see SELinux as enabled while faking selinux-disabled status when running semodule and semanage, then that might work. As a reminder, is_selinux_enabled() returns 1 if: 1) selinuxfs was found mounted on /selinux at startup, or 2) selinuxfs was found in /proc/mounts (mounted elsewhere) at startup, or 3) selinuxfs is found in /proc/filesystems, Thus, merely failing to mount selinuxfs within the chroot does not yield selinux-disabled status. You'd have to also not mount /proc. Or override is_selinux_enabled() in your own shared object. > > > > 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.... -- Stephen Smalley National Security Agency -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
