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