On Mon, 2008-05-12 at 10:45 -0400, Eric Paris wrote: > On Mon, 2008-05-12 at 08:08 -0400, Stephen Smalley wrote: > > On Fri, 2008-05-09 at 15:33 -0400, Eric Paris wrote: > > > On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote: > > > > 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. > > > > > > So I ran livecd-creator today with a couple of things inside the > > > chroot /selinux > > > > > > load -> /dev/null > > > null -> /dev/null > > > context = [blank file] > > > mls = 1 > > > enforcing = 1 > > > policyvers = 22 > > > > > > This was attempting to build a F9 livecd on an F9 box, so I wasn't > > > worried about the labeling issues (although the kernel in question is > > > patched to support unknown labels) > > > > > > Things blew up spectacularly :) > > > > > > warning: libgcc-4.3.0-8: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 > > > Installing: libgcc ##################### [ 1/129] > > > error: %post(libgcc-4.3.0-8.x86_64) scriptlet failed, exit status 255 > > > Installing: setup ##################### [ 2/129] > > > error: unpacking of archive failed on file /etc/bashrc: cpio: lsetfilecon > > > Installing: filesystem ##################### [ 3/129] > > > error: unpacking of archive failed on file /: cpio: lsetfilecon > > > Installing: basesystem ##################### [ 4/129] > > > Installing: ncurses-base ##################### [ 5/129] > > > error: unpacking of archive failed on file /etc/terminfo: cpio: lsetfilecon > > > > > > So I took a look at what's in "context" and I see > > > "t:s00s0s0s0s0s0s0s0s0s0:s0" which just seems horrible... I assume this > > > is a libselinux function using this. I wonder if I change that to use > > > O_TRUNC if things would go a bit more smoothly.... > > > > I think it would be better to just adjust userspace as we discussed to > > perform context validation against the target policy rather than the > > build host policy as is done by setfiles -c. > > On second thought is that even possible? As I recall > selinux-policy-targeted rpm is installed about 128/129 packages when I > do my livecd create. That means that we didn't even have an 'inside > chroot' policy to check against for the vast majority of this operation. > I'd assume that building the appropriete mock buildroot would have the > same problem. Wonder how people would feel about really hacking up the > buildroot creator to force install selinux stuff first and then run the > full install transaction set.... For a normal install, anaconda has to set down an initial file contexts file and load a policy to get things started IIRC - otherwise rpm wouldn't be able to label the files it sets down prior to installing selinux-policy*. > > Or disable context validation altogether in userspace in that instance. > > Anyone have suggestions on how to go about this? Absence of any /selinux/context at all should automatically do that. > > Or create some kind of "identity" node in the selinuxfs filesystem that > > is transaction-based like the existing selinuxfs nodes and always > > returns whatever was written to it, then bind mount that on top > > of /selinux/context. > > I did get that out of using a plain file and using O_TRUNC in libselinux > eventually. Yes, but I don't see how requiring the use of a hacked-up libselinux is any better or more workable. -- Stephen Smalley National Security Agency -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
