Fedora buildsys and SELinux

[Stephen Smalley]

On Mon, May 12, 2008 at 4:33 PM, Jeremy Katz <katzj at redhat.com> wrote:
> 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 :-/

That shouldn't actually be true - the fundamental test for whether or
not SELinux is enabled is the presence or absence of selinuxfs in
/proc/filesystems (i.e. is it registered in the kernel), not whether
or not selinuxfs is actually mounted anywhere.  The libselinux logic
should fall back to that /proc/filesystems test.

And looking at the libselinux code, it does appear to handle ENOENT on
/selinux/context by skipping the normal context validation, so not
having it present at all in /selinux within the chroot should help
_unless_ rpm calls matchpathcon() will outside of the chroot (that's
what I'm unclear on - when rpm is operating within the chroot and when
it is operating outside the chroot).

The only problem I see with not having selinuxfs mounted at all within
the chroot or even providing fake /selinux nodes is that rpm_execcon()
will then see SELinux as disabled and thus not try to run the
scriptlet in a different domain; it should just fall back to a normal
execve() in that situation.  Which could be addressed in policy
largely by collapsing rpm_script_t and rpm_t into a single domain.
I'm not sure how much we are using the distinction at present - I
think they are both effectively unconfined so it would only differ
possibly in outbound type transitions.

Anyway, I'd be interested in having Eric try the install with no
selinuxfs mounted or fake selinux nodes within the chroot and see what
happens, both in permissive mode and enforcing mode.