-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Smalley wrote: > On Tue, 2008-04-22 at 16:58 +0200, Tomas Mraz wrote: >>> Bill Nottingham wrote: >>>> James Morris (jmorris@xxxxxxxxx) 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@xxxxxxxxxx >>>> 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkgOOnAACgkQrlYvE4MpobNtGgCdGbX4swbPMBsnC+BpL6PTNEWM x4QAoKd+OpqR7ycGKZviGeb+ywYnQyjE =O3UV -----END PGP SIGNATURE----- -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
