Bug 1091761 - Sandbox stopped working
Summary: Sandbox stopped working
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: rawhide
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-04-27 21:52 UTC by Elad Alfassa
Modified: 2015-12-24 09:35 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-05-03 10:34:22 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
possible seunshare fix (1.97 KB, patch)
2014-05-01 05:03 UTC, Andy Lutomirski
no flags Details | Diff
much better fix (2.06 KB, patch)
2014-05-01 05:23 UTC, Andy Lutomirski
no flags Details | Diff

Description Elad Alfassa 2014-04-27 21:52:24 UTC
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

Comment 1 Miroslav Grepl 2014-04-28 12:34:11 UTC
If you execute

# yum reinstall selinux-policy-sandbox

does it blow up?

Comment 2 Elad Alfassa 2014-04-28 17:25:01 UTC
Same problem after reinstall.

Comment 3 Elad Alfassa 2014-04-28 17:25:38 UTC
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.

Comment 4 Milos Malik 2014-04-29 15:20:05 UTC
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

Comment 5 Miroslav Grepl 2014-04-30 12:52:29 UTC
(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?

Comment 6 Alexandru Constantin Minoiu 2014-05-01 00:26:49 UTC
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

Comment 7 Andy Lutomirski 2014-05-01 00:47:04 UTC
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.

Comment 8 Steve Grubb 2014-05-01 02:16:31 UTC
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.

Comment 9 Andy Lutomirski 2014-05-01 05:03:29 UTC
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.

Comment 10 Andy Lutomirski 2014-05-01 05:23:17 UTC
Created attachment 891393 [details]
much better fix

This version actually works.

Comment 11 Daniel Walsh 2014-05-01 12:25:07 UTC
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.

Comment 12 Alexandru Constantin Minoiu 2014-05-01 16:28:19 UTC
I've tested libcap-ng-0.7.4-2 and seunshare works now. Thanks Steve.

Comment 13 Andras Horvath 2014-07-04 12:37:44 UTC
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.

Comment 14 Florian Weimer 2014-07-04 14:05:05 UTC
(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.

Comment 15 Andras Horvath 2014-07-04 18:14:02 UTC
(In reply to Florian Weimer from comment #14)
> This is being dealt with in bug 1103622.

Thanks.

Comment 16 Josh Cogliati 2015-12-16 14:46:36 UTC
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

Comment 17 Paul Moore 2015-12-17 14:19:58 UTC
Hi Josh, would you mind creating a new BZ related to the issue you just posted here?

Comment 18 Josh Cogliati 2015-12-24 05:00:47 UTC
Created a new bugzilla for two sandbox problems:
https://bugzilla.redhat.com/show_bug.cgi?id=1294020


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