Fedora buildsys and SELinux

Daniel J Walsh dwalsh at redhat.com
Tue Apr 22 19:20:16 UTC 2008

Hash: SHA1

Stephen Smalley wrote:
> On Tue, 2008-04-22 at 16:58 +0200, Tomas Mraz wrote:
>>> Bill Nottingham wrote:
>>>> James Morris (jmorris at namei.org) said: 
>>>>>> * All the parties are here now needed to figure this out
>>>>>> * Someone better than me is going to reply with specifics about what is
>>>>>> not working in the buildsys
>>>>>> * We all agree it's pretty important to get this figured out in a good
>>>>>> way
>>>>> Can you please explain specifically what the problem is?
>>>> 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.
>>>> Bill
>>>> --
>>>> fedora-selinux-list mailing list
>>>> fedora-selinux-list at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>>> Just catching up on this email chain.
>>> The far more insidious problem is the act of loading policy in the
>>> chroot effects the kernel of the host.  So processes that are running in
>>> the host become invalidated when the client loads a policy.  This
>>> happens even in the case where you are building a chroot environment on
>>> the SAME os.  Since the spec file is running semanage commands to modify
>>> and add unconfined_t users, the unconfined processes of the parent and
>>> potential labels become unknown to the kernel for a period of time,
>>> which ends up labeling the files and processes as unlabeled_t.  When
>>> this happens files labeled unlabeled_t can not be accesses by confined
>>> process and if a process becomes unlabeled_t it will not be allowed any
>>> access on the box, which can cause the process to crash or go into in
>>> infinite loop.  If I build a livedvd, I end
>>> setenforce 0
>>> livedvd ...
>>> load_policy
>>> setenforce 1
>>> And sometimes I still need to
>>> fixfiles restore
>> Could it be solved by kernel preventing loading the policy when the
>> process which tries that is in the chroot? It seems to me that it
>> doesn't make any sense to allow that. Then with enabling creating files
>> with a context unknown to the policy the machine could run in enforcing
>> mode although the process which does the compose would of course have to
>> be unconfined.
> Why mount selinuxfs within the chroot at all?  Policy load isn't
> possible without selinuxfs.
> I had thought though that they wanted/needed to load the policy with
> scope limited to children of rpm so that package scriptlets will run in
> the correct domain and files created by them will be labeled as expected
> for the image being built rather than based on the host policy.   Which
> is rather complicated - it requires a per-process policy pointer and
> some way to deal with files that may be visible both to scriptlets
> within the chroot and to rpm and other processes outside of it.
Well currently livecd tools to a relabel at the end.  So we still have
the problem of the labels being correct when the dvd is complete.
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the fedora-selinux-list mailing list