On Mon, May 12, 2008 at 5:05 PM, Stephen Smalley <stephen.smalley@xxxxxxxxx> wrote: > > On Mon, May 12, 2008 at 4:33 PM, Jeremy Katz <katzj@xxxxxxxxxx> 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. > -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
