rpm is an application whose functionality is subject
to how policy is written.

The --root option is one prpblem, URI's for
packages on the command line are another problem,
not addressed in current targeted/strict policy.

This is a bug in libselinux.  The rpmexec should not fail in permissive mode. 
As far as running this in enforcing mode, we probably have other problems.

libselinux-1.21.1-3 in rawhide has this fix.

Is the problem that the chroot'ed environment has no /proc or
/selinux, and thus libselinux cannot access the SELinux API (via
/proc/pid/attr to get and set the context of the process, and via
/selinux to get the decision on what context to use for the helper)? 
Simply ignoring all errors and falling through to the execve isn't
good, as you could end up running a helper in rpm's own domain.

would the concept described in

http://listman.redhat.com/archives/rpm-list/2005-February/msg00027.html

solve the problems in strict mode?

As described, the two hooks wouldn't work for SELinux.
The pre_chroot hook occurs at the right time (i.e. while /proc is
still available), but lacks the necessary information to determine the
new security context for the helper (i.e. the helper program path and
any other security-relevant inputs like the signature verification
status), while the pre_exec hook occurs too late (after the chroot,
when we can no longer set the security context, as that also happens
via /proc/pid/attr).

If you just merged the two hooks into one hook that was called prior
to the chroot, that would suffice, as we don't dynamically switch the
context within the process - we just set the new context to use for
the next execve.  But that may not work as well for other schemes that
perform dynamic switching of e.g. uid, capabilities, whatever.  

Other option is to just add the additional inputs to the pre_chroot
hook call so that SELinux can do everything there, while still leaving
the separate pre_exec hook call for others to possibly use.

pre_chroot() could open /proc/self/attr and give the filedescriptor
in the delivered 'data' field (which is a private, hook specific
datastructure) to the pre_exec() hook.

The additional data (verify-status, argv[]...) could be given to the
pre_chroot hook also. But when the context switch happens before
chroot(2), the process would still need CAP_SYS_CHROOT capabilities.

The first approach would be too painful - we'd have to open, read, and
cache the content of /proc/self/attr/current (get current context),
open and save the descriptor to /proc/self/attr/exec (to later set
context for next execve in the pre_exec hook), and open and save the
descriptor to /selinux/create (to later compute the context for the
helper once we find out what it ias in the pre_exec hook), then use
the saved content and descriptors in the pre_exec hook and free and
close them.

Passing the additional data to the pre_chroot hook would be much
cleaner; then SELinux can do everything there.  It just sets the
context to use for the next execve; it won't affect the current
process until it performs the exec.

ok, I updated the proposal to give the required information to the
pre-chroot hook also

http://listman.redhat.com/archives/rpm-list/2005-February/msg00030.html

In my FC5 tests I turned on selinux and stumbled over this bug. Has it been
closed by accident? Can s/o with proper permissions reopen it and maybe reassign
it to either rpm or libselinux?

Is there currently no other way to use rpm with --root w/o turning off selinux
completely?

I forgot to add that the FC5 test was with selinux permissive.

Created attachment 125315 [details]
Change rpm_execcon to handle absence of selinuxfs in permissive mode

rpm_execcon had a fallback behavior if security_getenforce() returned 0 (i.e.
permissive), but security_getenforce() returns -1 if it cannot read
/selinux/enforce, which doesn't exist in the chroot.  This patch makes
rpm_execcon  fallback to a regular execve if security_getenforce() returns < 1,
i.e. permissive or unable to determine.
Enforcing case will still fail, not sure how to resolve w/o having rpm mount
selinuxfs and proc within the chroot environment so that the necessary APIs are
present.

This patch made it into 1.30 and thus FC5, thanks!

Stephen, does that mean that if I mount selinux and proc within the chroot
rpm(build) --root will properly work with selinux permissive and even enforced?

That would be acceptable, or not? E.g. would something like

o mkdir -p /the/root/{proc,selinux}
o mount -t proc proc /the/root/proc
o <how to mount selinuxfs under /the/root/selinux>
o rpm --root /the/root -Uhv foo.rpm bar.rpm
o rpmbuild --root /the/root --rebuild baz.src.rpm

work? That would be a great infrastructure to secure build environments (and to
allow the host to work under selinux).

How does one mount selinuxfs under /the/root/selinux?

Thanks!

I'm not certain how well it would work presently; in general, I wouldn't expect
permission problems under targeted policy (as rpm is unconfined there), just
strict policy.
selinuxfs can be mounted via mount -t selinuxfs <arbitrarystring>
/the/root/selinux, just like with proc.  We typically use "none" as the
<arbitrarystring>.
A quick test of doing the above sequence and doing a rpm --root /the/root -ivh
setup*.noarch.rpm ran to completion without denial, but the created files don't
seem to have the right contexts (just inherited from the parent directory by
default, not set to match file_contexts); I'm not sure why, as rpm should have
been able to read file_contexts from the main system prior to chroot'ing.

BTW, setfiles has a -r option for applying it to an alternate root directory, so
running:
/usr/sbin/setfiles -r /the/root
/etc/selinux/targeted/contexts/files/file_contexts /z
correctly labeled that tree.