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 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 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.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.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.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.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.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.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 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 on 2006-02-26 11:24 EST -- I forgot to add that the FC5 test was with selinux permissive. -- Additional comment from sds.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 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.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.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.
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.
Fixed in libselinux-1.19.1-7.2
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