Fedora buildsys and SELinux

[Stephen Smalley]

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