Yesterday I used sandbox and it worked fine. Today I ran yum update, and selinux-policy-sandbox and policycoreutils both updated. Now sandbox is not working. Observe: [elad@weatherwax ~]$ sudo yum install selinux-policy-sandbox [sudo] password for elad: Loaded plugins: auto-update-debuginfo, langpacks http://linux.dropbox.com/fedora/21/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found Trying other mirror. Package selinux-policy-sandbox-3.13.1-48.fc21.noarch already installed and latest version Nothing to do [elad@weatherwax ~]$ sandbox -M bash ERROR: could not find datum for type sandbox_t /usr/bin/sandbox: Sandbox Policy is not currently installed. You need to install the selinux-policy-sandbox package in order to run this command If I try to start an X sandbox, I get: Failed to execute command /usr/share/sandbox/sandboxX.sh: Operation not permitted This worked perfectly before this update. Relevant versions: selinux-policy-sandbox-3.13.1-48.fc21.noarch policycoreutils-sandbox-2.2.5-13.fc21.x86_64
If you execute # yum reinstall selinux-policy-sandbox does it blow up?
Same problem after reinstall.
Sorry, not exactly the same problem: [elad@weatherwax ~]$ sandbox -M bash Failed to execute command /usr/bin/bash: Operation not permitted Still doesn't work tho.
Sometimes I see following messages too: ERROR: could not find datum for type sandbox_t /usr/bin/sandbox: Sandbox Policy is not currently installed. You need to install the selinux-policy-sandbox package in order to run this command Following command usually helps: # semodule -e sandbox
(In reply to Elad Alfassa from comment #3) > Sorry, not exactly the same problem: > [elad@weatherwax ~]$ sandbox -M bash > Failed to execute command /usr/bin/bash: Operation not permitted > > Still doesn't work tho. Ok I see the same issue. Dan, is this a known issue or something new?
Hi, I'm on Fedora 20 and after I did yum update it broke the sandbox command. After a day of pain, I managed to fix this for now by downgrading libcap-ng . It seems the latest stable version pushed to Fedora 20 (0.7.4-1.fc20) makes some changes related to capabilities , and the current version of seunshare (package version 2.2.5-3.fc20 in policycoreutils-sandbox) does not like it at all. Related bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1035427 https://bugzilla.redhat.com/show_bug.cgi?id=885288
Yeah, seunshare -Z is broken now. See this code in the kernel: /* * Minimize confusion: if no_new_privs and a transition is * explicitly requested, then fail the exec. */ if (bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS) return -EPERM; Sigh. IMO the underlying issue is that process:transition makes no distinction between transitions caused by the selinux transition rules and transitions caused by explicit request. In the former case, no_new_privs should block any transition that is a privilege-gaining transition but, in the latter case, no_new_privs shouldn't really need to apply. But just dropping this rule is unsafe, since it's possible that process:transition is only granted for certain executables, and subverting them is easy in no_new_privs mode. As an interim fix, seunshare could attempt to dyntransition into the sandbox prior to execing anything. This probably requires a selinux policy change. This may be an important bugfix anyway -- what happens in older versions of cap-ng when trying to sandbox an executable that's on a nosuid filesystem? As a longer term fix, I think there should be a new selinux permission process:unprivileged_transition that grants the right to transition despite no_new_privs. And, for the record (again), I think that automatic transitions on exec are a disaster and should never have happened in the first place. They are two complicated for mortals to understand, and I think that both selinux and apparmor are rather buggy in their implementation. Heck, setuid has been poked and prodded at for decades, and it's still an unending source of security holes.
libcap-ng-0.7.4-2 was built in rawhide removing the call to prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0). Please give it a try and report your results. Thanks and sorry for the inconvenience.
Created attachment 891391 [details] possible seunshare fix I think that this will fix the problem for real. I've only tested it in permissive mode because I don't know how to write the appropriate policy rule to make it work.
Created attachment 891393 [details] much better fix This version actually works.
We can change the policy to allow the dyntrans, since the only thing the process is doing is the exec, The parent process has to stay in the previous context since it needs to be able to cleanup.
I've tested libcap-ng-0.7.4-2 and seunshare works now. Thanks Steve.
I have an up-to-date F20 x64 with Xfce desktop. Sandbox still doesn't work and I need to downgrade libcap-ng in order to fix it (from version 0.7.4-1 to 0.7.3-6). Could you tell me when version 0.7.4-2 will be available in F20? Or if it already there, how comes I cannpt upgrade to it? Thanks.
(In reply to Andras Horvath from comment #13) > I have an up-to-date F20 x64 with Xfce desktop. Sandbox still doesn't work > and I need to downgrade libcap-ng in order to fix it (from version 0.7.4-1 > to 0.7.3-6). This is being dealt with in bug 1103622.
(In reply to Florian Weimer from comment #14) > This is being dealt with in bug 1103622. Thanks.
For what it is worth, even with with selinux-policy-sandbox-3.13.1-157.fc23.noarch installed: ERROR: could not find datum for type sandbox_t /usr/bin/sandbox: Sandbox Policy is not currently installed. You need to install the selinux-policy-sandbox package in order to run this command But it did work after running: # semodule -e sandbox Possibly the error message should mention semodule -e sandbox
Hi Josh, would you mind creating a new BZ related to the issue you just posted here?
Created a new bugzilla for two sandbox problems: https://bugzilla.redhat.com/show_bug.cgi?id=1294020