-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Smalley wrote:
> On Mon, 2008-05-05 at 10:07 -0400, Eric Paris wrote:
>> On Mon, 2008-05-05 at 09:35 -0400, Stephen Smalley wrote:
>>> On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote:
>>>> On Tue, 2008-04-22 at 12:38 -0400, Stephen Smalley wrote:
>>>>> On Tue, 2008-04-22 at 11:55 -0400, Stephen Smalley wrote:
>>>>>> On Thu, 2008-04-17 at 09:12 -0400, Stephen Smalley wrote:
>>>>>>> On Wed, 2008-04-16 at 23:23 -0400, Bill Nottingham wrote:
>>>>>>>> James Morris (jmorris@namei.org) said:
>>>>>>>>>> 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.
>>>>>>>>> Ok, that's what I suspected.
>>>>>>>>>
>>>>>>>>> One of the possible plans for this is to allow a process to run in a
>>>>>>>>> separate policy namespace, and probably also utilize namespace support in
>>>>>>>>> general.
>>>>>>>>>
>>>>>>>>> This is non-trivial and needs more analysis.
>>>>>>>> Incidentally, this is also one of the blockers for policy-in-packages,
>>>>>>>> rather than a monolithic one.
>>>>>>> I assume you mean setting down unknown file labels rather than
>>>>>>> per-namespace or per-chroot policy support. I think they are related
>>>>>>> but different. The former is required if you always plan to install the
>>>>>>> files _before_ loading the policy. The latter is required primarily for
>>>>>>> getting any scriptlets to run in the right security contexts so that any
>>>>>>> files they create are labeled appropriately within the chroot.
>>>>>> BTW, for reference, a patch to support setting down unknown file labels
>>>>>> was posted here a couple of years ago:
>>>>>> http://marc.info/?l=selinux&m=114771094617968&w=2
>>>>> And the last version of that patch was:
>>>>> http://marc.info/?l=selinux&m=114840466518263&w=2
>>>>> Not that it applies cleanly anymore, of course.
>>>> An updated patch and discussion has started over on selinux list, see:
>>>> http://marc.info/?t=120958955400002&r=1&w=2
>>>>
>>>> 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.
>>> We need to better understand the sequence of actions performed by rpm,
>>> both from outside the chroot and from within the chroot, to know
>>> precisely what is needed here.
>>>
>>> It would be cleaner if we could just disable policy reload altogether.
>>> libsemanage will skip policy reload if:
>>> 1) the caller asked to skip reload (e.g. semodule with the -n option) or
>>> 2) the caller asked to operate on a policy store other than the active
>>> policy store (e.g. semodule with the -s option), or
>>> 3) SELinux appears to be disabled.
>>>
>>> We can fake the last one, but I think that will confuse rpm with respect
>>> to other actions we still want it to take, like labeling the files,
>>> transitioning to a scriptlet domain, etc.
>> In this case is scriptlet transition really important? What is to be
>> gained? Its not like we are getting file transitions...
>
> IIRC, failure to transition to rpm_script_t has caused problems in the
> past, either with denials or subsequent domain transitions or subsequent
> file transitions.
>
> If we could ensure that rpm and forked children prior to exec continue
> to see SELinux as enabled while faking selinux-disabled status when
> running semodule and semanage, then that might work.
>
> As a reminder, is_selinux_enabled() returns 1 if:
> 1) selinuxfs was found mounted on /selinux at startup, or
> 2) selinuxfs was found in /proc/mounts (mounted elsewhere) at startup,
> or
> 3) selinuxfs is found in /proc/filesystems,
>
> Thus, merely failing to mount selinuxfs within the chroot does not yield
> selinux-disabled status. You'd have to also not mount /proc. Or
> override is_selinux_enabled() in your own shared object.
>
>>> On the context validation/canonicalization, it would be cleaner if we
>>> could have rpm validate and canonicalize against the target image's
>>> policy rather than the build host's policy. This is likely doable, as
>>> setfiles has to do something like this for its -c option when validating
>>> a file contexts configuration against a policy at policy build time.
>>> Requires calling a libselinux interface to register an alternative
>>> validate callback.
>> This sounds like a great idea, but is clearly going to take work from
>> the RPM people....
I think a lot of this is experimental. The easiest thing would to first
get livecd creation to work. Once we have a workable solution there we
could probably extend it to Mock and other parts of the Fedora
Infrastructure.

Offhand we need to handle calls made by semodule, restorecon/setfiles,
potential problems with udev, rpmscript execution.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkggm+YACgkQrlYvE4MpobN25wCeITCT9Kj4Ql gIk/mVKEaH7eAD
ahIAn2iwFNxqQdOp56M8c1dQcPASuSj2
=IJzJ
-----END PGP SIGNATURE-----

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

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....

-Eric

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

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

So I added O_TRUNC to both of the callers to /selinux/context in
libselinux and that took care of the lsetfilecon() crap but I still get
tons and tons of "scriptlet failed, exit status 255"

Anyone have ideas/suggestions how to debug those more?

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]
Installing: filesystem ##################### [ 3/129]
Installing: basesystem ##################### [ 4/129]
Installing: ncurses-base ##################### [ 5/129]
Installing: tzdata ##################### [ 6/129]
Installing: rootfiles ##################### [ 7/129]
Installing: glibc ##################### [ 8/129]
error: %post(glibc-2.8-3.x86_64) scriptlet failed, exit status 255
Installing: ncurses-libs ##################### [ 9/129]
error: %post(ncurses-libs-5.6-16.20080301.fc9.x86_64) scriptlet failed, exit status 255
Installing: popt ##################### [ 10/129]
error: %post(popt-1.13-3.fc9.x86_64) scriptlet failed, exit status 255
Installing: zlib ##################### [ 11/129]
error: %post(zlib-1.2.3-18.fc9.x86_64) scriptlet failed, exit status 255

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

On Fri, 09 May 2008 16:00:17 -0400
Eric Paris <eparis@redhat.com> 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
>
> So I added O_TRUNC to both of the callers to /selinux/context in
> libselinux and that took care of the lsetfilecon() crap but I still
> get tons and tons of "scriptlet failed, exit status 255"
>
> Anyone have ideas/suggestions how to debug those more?
>
> 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]
> Installing: filesystem #####################
> [ 3/129] Installing: basesystem
> ##################### [ 4/129] Installing:
> ncurses-base ##################### [ 5/129]
> Installing: tzdata #####################
> [ 6/129] Installing: rootfiles
> ##################### [ 7/129] Installing:
> glibc ##################### [ 8/129] error:
> %post(glibc-2.8-3.x86_64) scriptlet failed, exit status 255
> Installing: ncurses-libs #####################
> [ 9/129] error: %post(ncurses-libs-5.6-16.20080301.fc9.x86_64)
> scriptlet failed, exit status 255 Installing:
> popt ##################### [ 10/129] error:
> %post(popt-1.13-3.fc9.x86_64) scriptlet failed, exit status 255
> Installing: zlib #####################
> [ 11/129] error: %post(zlib-1.2.3-18.fc9.x86_64) scriptlet failed,
> exit status 255

These all look like library packages so I'd hazard a guess that the
thing that's failing is ldconfig. Perhaps you could replace ldconfig
with a wrapper than runs it under strace?

Paul.

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

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.

Or disable context validation altogether in userspace in that instance.

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.

--
Stephen Smalley
National Security Agency

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

On Fri, 2008-05-09 at 16:00 -0400, Eric Paris 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
>
> So I added O_TRUNC to both of the callers to /selinux/context in
> libselinux and that took care of the lsetfilecon() crap but I still get
> tons and tons of "scriptlet failed, exit status 255"
>
> Anyone have ideas/suggestions how to debug those more?

Ah, it is likely failing on the rpm_execcon(3) ->
security_compute_create(3) call i.e. writing to /selinux/create.
Which computes the context in which to run the scriptlet or helper from
the policy. If that returns the same as rpm's own context, then we fall
back to rpm_script_t. So this affects things like ldconfig.

I increasingly suspect we're better off not mounting selinuxfs within
the chroot at all and addressing any issues that arise via policy.

> 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]
> Installing: filesystem ##################### [ 3/129]
> Installing: basesystem ##################### [ 4/129]
> Installing: ncurses-base ##################### [ 5/129]
> Installing: tzdata ##################### [ 6/129]
> Installing: rootfiles ##################### [ 7/129]
> Installing: glibc ##################### [ 8/129]
> error: %post(glibc-2.8-3.x86_64) scriptlet failed, exit status 255
> Installing: ncurses-libs ##################### [ 9/129]
> error: %post(ncurses-libs-5.6-16.20080301.fc9.x86_64) scriptlet failed, exit status 255
> Installing: popt ##################### [ 10/129]
> error: %post(popt-1.13-3.fc9.x86_64) scriptlet failed, exit status 255
> Installing: zlib ##################### [ 11/129]
> error: %post(zlib-1.2.3-18.fc9.x86_64) scriptlet failed, exit status 255


--
Stephen Smalley
National Security Agency

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

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....

> Or disable context validation altogether in userspace in that instance.

Anyone have suggestions on how to go about this?

> 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.

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

Eric Paris (eparis@redhat.com) said:
> 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....

Due to dependencies, you can never load the policy 'first'.

Bill

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

On Mon, 2008-05-12 at 08:17 -0400, Stephen Smalley wrote:
> On Fri, 2008-05-09 at 16:00 -0400, Eric Paris wrote:
> > So I added O_TRUNC to both of the callers to /selinux/context in
> > libselinux and that took care of the lsetfilecon() crap but I still get
> > tons and tons of "scriptlet failed, exit status 255"
> >
> > Anyone have ideas/suggestions how to debug those more?
>
> Ah, it is likely failing on the rpm_execcon(3) ->
> security_compute_create(3) call i.e. writing to /selinux/create.
> Which computes the context in which to run the scriptlet or helper from
> the policy. If that returns the same as rpm's own context, then we fall
> back to rpm_script_t. So this affects things like ldconfig.
>
> I increasingly suspect we're better off not mounting selinuxfs within
> the chroot at all and addressing any issues that arise via policy.

If we don't mount selinuxfs, then anything that attempts to figure out
if SELinux is enabled (ie the fact that rpm checks if SELinux is enabled
to determine whether or not to set the xattrs) will fail. Also, I don't
remember for certain without looking, but even restorecon checks like
that from what I remember. So we have to at least have some of /selinux
present or we have to do deeper tricks with labeling outside of chroots
which ... pain :-/

Jeremy

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list