Fedora buildsys and SELinux

Tue May 6 17:56:54 UTC 2008

-----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 at namei.org) 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-----