On Tue, Apr 22, 2008 at 3:20 PM, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Stephen Smalley wrote:
> On Tue, 2008-04-22 at 16:58 +0200, Tomas Mraz wrote:
>>> Bill Nottingham wrote:
>>>> James Morris (jmorris(a)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
>>>>>> not working in the buildsys
>>>>>> * We all agree it's pretty important to get this figured
out in a good
>>>>> 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.
>>>> fedora-selinux-list mailing 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 ...
>>> 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.
I am trying to keep up with this conversation and I don't expect
anyone to stop and explain all this but....
Can the image be built on a remote host?or a virtualized one(i caught
but do not completely understand the comment about being unable to
virtualize SELinux)? Would this not rather neatly avoid the chroot
problem(assuming I am understanding the problem correctly)? Which if i
understand it right is that you cannot load policy in the chroot
because the policy applies itself or is getting applied to the running
kernel even though it is not intended for that kernel but the one in
the image, which is of course not running. Perhaps these things have
been considered already but are not feasible? Mind you I have no idea
how to implement this, I am just beating my little gnat wings off the
west coast of Africa hoping I can cause the typhoon in south america.
I haven't been able to find much in the way of documentation on the
fedora build system. if anyone has a pointer to good docs, assuming
they exist, I would appreciate the link, what little I have found
seems incomplete or unfinished.