Bug 145770 - '--root' + SELinux makes scriptlets fail
'--root' + SELinux makes scriptlets fail
Product: Fedora
Classification: Fedora
Component: selinux-policy-strict (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Mike McLean
Depends On:
Blocks: 202035
  Show dependency treegraph
Reported: 2005-01-21 08:08 EST by Enrico Scholz
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version: 1.25.4-10.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-15 11:57:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Change rpm_execcon to handle absence of selinuxfs in permissive mode (540 bytes, patch)
2006-02-27 08:30 EST, Stephen Smalley
no flags Details | Diff

  None (edit)
Description Enrico Scholz 2005-01-21 08:08:08 EST
Description of problem:

| # mkdir /tmp/rootfs
| # rpm --root /tmp/rootfs -U glibc-common-2.3.3-74.i386.rpm tzdata-2004e-2.noarch.rpm basesystem-8.0-4.noarch.rpm setup-2.5.36-1.noarch.rpm filesystem-2.3.0-1.i386.rpm 
| warning: glibc-common-2.3.3-74.i386.rpm: V3 DSA signature: NOKEY, key ID 4f2a6fd2
| error: %post(glibc-common-2.3.3-74.i386) scriptlet failed, exit status 255

(Files are from FC3)

Same happens with every other scriptlet.

SELinux is in permissive mode with targeted policy, no errors are

| [root@morden RPMS]# id -Z
| root:system_r:unconfined_t
| [root@morden RPMS]# rpm -V rpm
| S.5....T. c /etc/logrotate.d/rpm
| [root@morden RPMS]#

Version-Release number of selected component (if applicable):


vanilla kernel-2.6.10

How reproducible:

Comment 1 Jeff Johnson 2005-01-23 09:52:03 EST
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.
Comment 2 Daniel Walsh 2005-01-24 15:50:52 EST
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.
Comment 3 Stephen Smalley 2005-01-24 16:10:25 EST
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.
Comment 4 Enrico Scholz 2005-02-04 09:15:00 EST
would the concept described in


solve the problems in strict mode?
Comment 5 Stephen Smalley 2005-02-04 09:26:10 EST
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.
Comment 6 Enrico Scholz 2005-02-04 09:39:29 EST
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.
Comment 7 Stephen Smalley 2005-02-04 09:56:53 EST
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.
Comment 8 Enrico Scholz 2005-02-04 10:23:11 EST
ok, I updated the proposal to give the required information to the
pre-chroot hook also

Comment 9 Axel Thimm 2006-02-26 10:03:32 EST
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
Comment 10 Axel Thimm 2006-02-26 11:24:39 EST
I forgot to add that the FC5 test was with selinux permissive.
Comment 11 Stephen Smalley 2006-02-27 08:30:31 EST
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
Comment 12 Axel Thimm 2006-03-30 18:49:18 EST
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?

Comment 13 Stephen Smalley 2006-03-31 07:53:40 EST
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
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.
Comment 14 Stephen Smalley 2006-03-31 07:57:22 EST
BTW, setfiles has a -r option for applying it to an alternate root directory, so
/usr/sbin/setfiles -r /the/root
/etc/selinux/targeted/contexts/files/file_contexts /z
correctly labeled that tree.

Note You need to log in before you can comment on or make changes to this bug.