Fedora buildsys and SELinux

Stephen Smalley stephen.smalley at gmail.com
Mon May 12 21:19:33 UTC 2008

On Mon, May 12, 2008 at 5:05 PM, Stephen Smalley
<stephen.smalley at gmail.com> wrote:
> 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;

Ah, sorry - I misspoke above.  Since is_selinux_enabled() ultimately
comes down to presence/absence of selinuxfs in /proc/filesystems,
rpm_execcon() will see SELinux as enabled but the
security_compute_create() call will fail and this will cause it to
abort rather than execve().  That's the problem Eric presently has.
So possibly changing rpm_execcon() to fall back to setting the default
domain to rpm_script_t and proceeding if security_compute_create()
fails would allow him to proceed.  That would still leave us in
rpm_script_t rather than ldconfig_t, so we'd have a labeling problem,
but that's likely fixable via a selective restorecon after the fact.

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

More information about the fedora-selinux-list mailing list