Bug 145770
Summary: | '--root' + SELinux makes scriptlets fail | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Enrico Scholz <rh-bugzilla> | ||||
Component: | selinux-policy-strict | Assignee: | Daniel Walsh <dwalsh> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Mike McLean <mikem> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | low | ||||||
Version: | rawhide | CC: | axel.thimm, nobody+pnasrat, sdsmall, thomas | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | 1.25.4-10.1 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2005-09-15 15:57:20 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 202035 | ||||||
Attachments: |
|
Description
Enrico Scholz
2005-01-21 13:08:08 UTC
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. |