Bug 202035 - "--root" + SELinux makes scriptlets fail
"--root" + SELinux makes scriptlets fail
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: libselinux (Show other bugs)
4.4
All Linux
high Severity high
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On: 145770
Blocks: 196038
  Show dependency treegraph
 
Reported: 2006-08-10 10:37 EDT by Daniel Riek
Modified: 2007-11-16 20:14 EST (History)
5 users (show)

See Also:
Fixed In Version: RHBA-2007-0226
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-01 18:50:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Riek 2006-08-10 10:37:41 EDT
On IBM's list of important features and relevant to their x86 emulator on power.

+++ This bug was initially created as a clone of Bug #145770 +++

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

| [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):

rpm-4.3.3-8
libselinux-1.20.1-2

vanilla kernel-2.6.10


How reproducible:

100%

-- Additional comment from jbj@redhat.com on 2005-01-23 09:52 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.

-- Additional comment from dwalsh@redhat.com on 2005-01-24 15:50 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.

-- Additional comment from sds@tycho.nsa.gov on 2005-01-24 16:10 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.

-- Additional comment from enrico.scholz@informatik.tu-chemnitz.de on 2005-02-04
09:15 EST --
would the concept described in

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

solve the problems in strict mode?

-- Additional comment from sds@tycho.nsa.gov on 2005-02-04 09:26 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.

-- Additional comment from enrico.scholz@informatik.tu-chemnitz.de on 2005-02-04
09:39 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.


-- Additional comment from sds@tycho.nsa.gov on 2005-02-04 09:56 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.


-- Additional comment from enrico.scholz@informatik.tu-chemnitz.de on 2005-02-04
10:23 EST --
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

-- Additional comment from Axel.Thimm@ATrpms.net on 2006-02-26 10:03 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
completely?


-- Additional comment from Axel.Thimm@ATrpms.net on 2006-02-26 11:24 EST --
I forgot to add that the FC5 test was with selinux permissive.


-- Additional comment from sds@tycho.nsa.gov on 2006-02-27 08:30 EST --
Created an attachment (id=125315)
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.


-- Additional comment from Axel.Thimm@ATrpms.net on 2006-03-30 18:49 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?

Thanks!

-- Additional comment from sds@tycho.nsa.gov on 2006-03-31 07:53 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
<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.


-- Additional comment from sds@tycho.nsa.gov on 2006-03-31 07:57 EST --
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.
Comment 2 RHEL Product and Program Management 2006-08-18 10:44:42 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 5 Daniel Walsh 2007-01-30 15:58:56 EST
Fixed in libselinux-1.19.1-7.2
Comment 9 Red Hat Bugzilla 2007-05-01 18:50:47 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0226.html

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