-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Smalley wrote: > 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.... I think a lot of this is experimental. The easiest thing would to first get livecd creation to work. Once we have a workable solution there we could probably extend it to Mock and other parts of the Fedora Infrastructure. Offhand we need to handle calls made by semodule, restorecon/setfiles, potential problems with udev, rpmscript execution. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkggm+YACgkQrlYvE4MpobN25wCeITCT9Kj4QlgIk/mVKEaH7eAD ahIAn2iwFNxqQdOp56M8c1dQcPASuSj2 =IJzJ -----END PGP SIGNATURE----- -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
