Bug 1103622 - sandbox -X is completely broken
Summary: sandbox -X is completely broken
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: policycoreutils
Version: 24
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Petr Lautrbach
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1093702 1105652 1105798 1111109 1173590 1176022 1212984 (view as bug list)
Depends On:
Blocks: 1357115
TreeView+ depends on / blocked
 
Reported: 2014-06-02 08:38 UTC by Petr Lautrbach
Modified: 2016-07-20 07:18 UTC (History)
40 users (show)

Fixed In Version: policycoreutils-2.5-12.fc24
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1357115 (view as bug list)
Environment:
Last Closed: 2016-07-20 00:21:03 UTC


Attachments (Terms of Use)

Description Petr Lautrbach 2014-06-02 08:38:17 UTC
policycoreutils-python-2.3-5.fc21.x86_64
selinux-policy-3.13.1-55.fc21.noarch

command:
$ sandbox -X -t sandbox_web_t firefox 

AVCs in permissive mode:

----
time->Mon Jun  2 10:33:18 2014
type=UNKNOWN[1327] msg=audit(1401697998.436:562): proctitle=2F7573722F62696E2F586570687972002D726573697A6561626C65002D7469746C650053616E64626F782073616E64626F785F7765625F743A73303A63313030312C6331303232202D2D20202F7573722F62696E2F66697265666F7820002D7465726D696E617465002D73637265656E003130303078373030002D6470690039
type=SYSCALL msg=audit(1401697998.436:562): arch=c000003e syscall=42 success=yes exit=0 a0=0 a1=7fffe29aebd0 a2=14 a3=107 items=0 ppid=2925 pid=2934 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=1 comm="Xephyr" exe="/usr/bin/Xephyr" subj=unconfined_u:unconfined_r:sandbox_web_t:s0:c1001,c1022 key=(null)
type=AVC msg=audit(1401697998.436:562): avc:  denied  { connectto } for  pid=2934 comm="Xephyr" path=002F746D702F2E5831312D756E69782F5830 scontext=unconfined_u:unconfined_r:sandbox_web_t:s0:c1001,c1022 tcontext=system_u:system_r:xserver_t:s0-s0:c0.c1023 tclass=unix_stream_socket
----
time->Mon Jun  2 10:33:19 2014
type=UNKNOWN[1327] msg=audit(1401697999.471:563): proctitle="/usr/lib64/firefox/firefox"
type=SYSCALL msg=audit(1401697999.471:563): arch=c000003e syscall=2 success=yes exit=28 a0=7fe8f2f59a40 a1=42 a2=180 a3=120 items=0 ppid=2949 pid=2953 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=1 comm="firefox" exe="/usr/lib64/firefox/firefox" subj=unconfined_u:unconfined_r:sandbox_web_t:s0:c1001,c1022 key=(null)
type=AVC msg=audit(1401697999.471:563): avc:  denied  { open } for  pid=2953 comm="firefox" path="/run/user/1000/dconf/user" dev="tmpfs" ino=25427 scontext=unconfined_u:unconfined_r:sandbox_web_t:s0:c1001,c1022 tcontext=unconfined_u:object_r:config_home_t:s0 tclass=file
----
time->Mon Jun  2 10:33:19 2014
type=UNKNOWN[1327] msg=audit(1401697999.478:564): proctitle="/usr/lib64/firefox/firefox"
type=SYSCALL msg=audit(1401697999.478:564): arch=c000003e syscall=42 success=no exit=-115 a0=20 a1=7fe8fab1ba00 a2=1c a3=107 items=0 ppid=2949 pid=2989 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=1 comm=536F636B657420546872656164 exe="/usr/lib64/firefox/firefox" subj=unconfined_u:unconfined_r:sandbox_web_t:s0:c1001,c1022 key=(null)
type=AVC msg=audit(1401697999.478:564): avc:  denied  { name_connect } for  pid=2989 comm=536F636B657420546872656164 dest=9050 scontext=unconfined_u:unconfined_r:sandbox_web_t:s0:c1001,c1022 tcontext=system_u:object_r:tor_port_t:s0 tclass=tcp_socket
----
time->Mon Jun  2 10:33:20 2014
type=UNKNOWN[1327] msg=audit(1401698000.068:565): proctitle="/usr/lib64/firefox/firefox"
type=SYSCALL msg=audit(1401698000.068:565): arch=c000003e syscall=42 success=no exit=-115 a0=2e a1=7fe8fab1b9f0 a2=10 a3=0 items=0 ppid=2949 pid=2989 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=1 comm=536F636B657420546872656164 exe="/usr/lib64/firefox/firefox" subj=unconfined_u:unconfined_r:sandbox_web_t:s0:c1001,c1022 key=(null)
type=AVC msg=audit(1401698000.068:565): avc:  denied  { name_connect } for  pid=2989 comm=536F636B657420546872656164 dest=443 scontext=unconfined_u:unconfined_r:sandbox_web_t:s0:c1001,c1022 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket
----
time->Mon Jun  2 10:33:24 2014
type=UNKNOWN[1327] msg=audit(1401698004.598:566): proctitle="/usr/libexec/at-spi-bus-launcher"
type=SYSCALL msg=audit(1401698004.598:566): arch=c000003e syscall=42 success=no exit=-111 a0=a a1=2410d10 a2=1c a3=7fff3521ed94 items=0 ppid=1 pid=3018 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=1 comm="at-spi-bus-laun" exe="/usr/libexec/at-spi-bus-launcher" subj=unconfined_u:unconfined_r:sandbox_web_t:s0:c1001,c1022 key=(null)
type=AVC msg=audit(1401698004.598:566): avc:  denied  { name_connect } for  pid=3018 comm="at-spi-bus-laun" dest=6001 scontext=unconfined_u:unconfined_r:sandbox_web_t:s0:c1001,c1022 tcontext=system_u:object_r:xserver_port_t:s0 tclass=tcp_socket

Comment 1 Miroslav Grepl 2014-06-02 09:00:41 UTC
Ok we are getting these issues with updated libcap-ng but it works with older libcap-ng version + latest policycoreutils/selinux-policy sandbox fixes.

Comment 2 Steve Grubb 2014-06-02 14:21:14 UTC
There were 3 fixes needed. One was libcap-ng needed to set no_new_privs. The next was policycoreutils needed from bug 1091761. That in turn required a selinux policy update.

So, is this bz saying that when a user has all 3 packages updated, we have a problem?

Comment 3 Petr Lautrbach 2014-06-02 14:23:54 UTC
I updated my rawhide this morning and I can't run sandbox

libcap-ng-0.7.4-3.fc21.x86_64
selinux-policy-3.13.1-55.fc21.noarch
policycoreutils-python-2.3-5.fc21.x86_64

Comment 5 Miroslav Grepl 2014-06-02 15:06:24 UTC
> So, is this bz saying that when a user has all 3 packages updated, we have a
> problem?

Yes. And we are getting AVC msgs which Petr reported.

Comment 6 Steve Grubb 2014-06-02 15:47:09 UTC
Can this be fixed with more work on dynamic transitions like done on bug 1091761? Its pretty clear that because of CVE-2014-3215 we have to set no new privs. I had questioned if no_new_privs really was the right solution or if the kernel needed something different. But if dynamic transitions can fix it, then we should. If this points to endless fixes as each program gets used in the sandbox, then maybe we should revisit the kernel problem.

Comment 7 Miroslav Grepl 2014-06-05 09:35:05 UTC
Ok, the problem is we end up in sandbox_web_t instead of sandbox_xserver_t for Xephyr.

[{Xephyr}(`unconfined_u:unconfined_r:sandbox_xserver_t:s0:c123,c354')]

vs.

[{Xephyr}(`unconfined_u:unconfined_r:sandbox_web_t:s0:c123,c354')]

Comment 8 Miroslav Grepl 2014-06-05 13:11:44 UTC
So the point is we end up with sandbox_web_t at all if we run 

sandbox -X -t sandbox_web_t firefox

and we don't have transitions to sandbox_web_client, sandbox_xserver_t for Xephyr, openbox ...

Comment 9 Miroslav Grepl 2014-06-05 14:28:46 UTC
Unfortunately I don't see a way how to fix it in policycoreutils now. Basically we execute the sandboxX.sh helper script which executes Xephyr, openbox. So no way to use dyntrans in this case.

Comment 10 Daniel Walsh 2014-06-05 19:41:58 UTC
So we really need a way to tell the kernel that we want transitions to continue to happen but nosuid.

Comment 11 Paul Moore 2014-06-05 20:09:11 UTC
(In reply to Daniel Walsh from comment #10)
> So we really need a way to tell the kernel that we want transitions to
> continue to happen but nosuid.

Let me try to summarize this for my own understanding ... the sandbox tool recently enabled NNP which broke all of the SELinux domain transitions, yes?  I am a little confused by Dan's last comment, does the sandbox tool also try to run programs from a nosuid mounted filesystem?

Comment 12 Miroslav Grepl 2014-06-06 16:32:11 UTC
*** Bug 1105652 has been marked as a duplicate of this bug. ***

Comment 13 Lukas Vrabec 2014-06-08 10:40:27 UTC
*** Bug 1105798 has been marked as a duplicate of this bug. ***

Comment 14 Daniel Walsh 2014-06-09 11:30:26 UTC
Paul what you said is correct,  NNP is breaking sandbox domain transitions which is causing 

sandbox_web_t @ xserver_exec_t -> sandbox_xserver_t to not happen.  This means the Xephyr is running in the sandbox_web_t domain, and attempting to connect to the host X Server.  If we allow this, then the sandbox app can watch keystrokes, read cut buffer and screen scrape the host.  Basically breaks the isolation we were after.

We need to allow NNP and SELinux transitions some how.

Comment 15 Eric Paris 2014-06-09 14:07:51 UTC
Linus was very clear when he implemented NNP.  NNP = No transitions EVER.

You can't gain or LOSE permissions after NNP.

(remember the sendmail bug was because of lost permissions...)

This will take some thought.  Maybe you'll want to solve it by having a specific 'transition under NNP' security check?  Which might make Linus happy (or he wouldn't know)

Comment 16 Andy Lutomirski 2014-06-10 22:32:05 UTC
Um.  I implemented NNP, not Linus.  And you can lose permissions.

I just replied to an old off-list thread to see if we can restart this thing.

Alternatively, someone could rewrite seunshare to use user namespaces instead of being setuid.  That would probably reduce the code size by 80%, make it less scary, and fix this issue as a side effect.  Not to mention significantly improving debugability.

Comment 17 Eric Paris 2014-06-11 12:55:42 UTC
Andy, so sorry, I meant 'when he was dictating what he would accept in an implementation'.  You do deserve the credit.

My words:
"My thought on expanding the SELinux support beyond 'no
transition' (which I suggest we do today) would be that we might allow
SELinux transitions if we can show the the 'child' domain is a subset of
the 'parent' domain."


His words:
"No, you can't drop capabilities. You're in a sandbox, the whole point
is that you're running untrusted code, you had better not *have* any
capabilities that you worry about dropping."

Maybe he's changed his mind, but I'm not seeing the wiggle room...

Comment 18 Andy Lutomirski 2014-06-11 18:22:57 UTC
No offense taken.

For what it's worth, in every kernel that's supported no_new_privs, there's nothing that would prevent you from dropping capabilities after setting no_new_privs.  And sandbox (without -X) can successfully drop privs.

So I'm all for making nnp more flexible as long as the important security part doesn't break, and I'll happily defend it to Linus if needed.

Comment 19 Andras Horvath 2014-07-04 18:18:04 UTC
subscribe

Comment 20 Richard Z. 2014-08-13 13:04:09 UTC
Same problem in Fedora 19 btw.

Comment 21 Andy Lutomirski 2014-09-01 21:54:06 UTC
The bounded transition under no_new_privs patch is now in selinux-next:

http://git.infradead.org/users/pcmoore/selinux/commit/7b0d0b40cd78cadb525df760ee4cac151533c2b5

If that patch plus a small policy change could fix that, I wouldn't be surprised if the kernel team would be willing to backport the patch.

Comment 22 Šimon Lukašík 2014-09-04 18:40:46 UTC
*** Bug 1111109 has been marked as a duplicate of this bug. ***

Comment 23 Matthew Davis 2014-09-15 03:05:50 UTC
Probably no surprise, but still exists in F20 (selinux-policy-3.12.1-182.fc20.noarch / xorg-x11-server-Xephyr-1.14.4-11.fc20.x86_64).

Comment 24 Simo Sorce 2014-09-16 16:07:30 UTC
Matthew, so far the only workaround is to downgrade libcap-ng to the one released at F20 GA ... which is less then ideal.

Comment 25 dmunk 2014-11-04 20:38:21 UTC
Hello,

I am not a developer. Just wanted that out of the way. 

So, what is the plan b? I mean, is it not possible to restrict a 'firefox

chome\|browser' to a sandboxed environment? I have seen the sandfox script. However, it would be ideal to have a chrooted, selinux enforced environment to use a browser from. How cool would be to isolate java and flash from anything on the local system in the off chance that some breach comes about?

I almost set up a one off policy going off all the "how-to" documentation floating around for firefox sandboxing. I helpd back once I came across this. Would the patch that Andy Lutomirski posted be the solution?

Thanks.

Comment 26 Andy Lutomirski 2014-11-04 20:42:28 UTC
I think that the right solution long term doesn't involve selinux at all.  I keep meaning to write a little "nsbox" program to create a sandbox using user namespaces and put something in it.  No privilege would be needed, nor would there be any setuid root things, and all of the incomprehensibilities that make the selinux sandbox hard to maintain would be irrelevant.

Of course, you could later selinux on top of that, too, but if it broke, you could turn it off.

Comment 27 dmunk 2014-11-04 20:59:55 UTC
So, if I am understanding correctly, the below would totally negate the sandbox?

====
module mypol 1.0;

require {
	type sandbox_web_t;
	type http_port_t;
	class tcp_socket name_connect;
}

#============= sandbox_web_t ==============

#!!!! This avc can be allowed using the boolean 'nis_enabled'
allow sandbox_web_t http_port_t:tcp_socket name_connect;

====

I am still going through reading https://www.packtpub.com/networking-and-servers/selinux-system-administration. So, I dont have a full grasp of the implications of many of the rules that would be broken when using what is suggested by using line from setroubleshootd.

Thanks for your time.

Comment 28 Alphonse Steiner 2014-11-18 09:19:16 UTC
Until this bug is fixed, please could you:
 - put & keep libcap-ng 0.7.3-6 in the repository;
 - mark a conflict or version dependancy in the packages.

The idea here is to let the users informed of the problem, and to give them a workaround ("yum dowgrade libcap-ng"), so that users can still use 'sandbox -X'.

Comment 29 Lukas Vrabec 2014-12-16 14:43:18 UTC
*** Bug 1173590 has been marked as a duplicate of this bug. ***

Comment 30 Marian Csontos 2015-02-02 09:22:12 UTC
*** Bug 1176022 has been marked as a duplicate of this bug. ***

Comment 31 Andy Lutomirski 2015-02-02 14:57:35 UTC
Dan, do you know what's going on here?  I have the impression that this is broken for users who upgraded to F21 but is working for new installs, but I could be wrong about that.

Comment 32 Richard Z. 2015-02-02 20:47:53 UTC
I did upgrade to F21 and it worked as long as I kept the old versionlock. After removing the versionlock and doing update it no longer worked.

So back to 
# yum versionlock
0:libcap-ng-0.7.3-3.fc19.*

Comment 33 Jaroslav Reznik 2015-03-03 15:51:44 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 34 Andy Lutomirski 2015-03-06 02:55:54 UTC
*** Bug 1093702 has been marked as a duplicate of this bug. ***

Comment 35 Andy Lutomirski 2015-03-06 03:00:29 UTC
I've confirmed that the Fedora 22 Alpha TC 8 live cd has this problem.

Moving to policycoreutils, which is closer than libcap-ng to describing the actual problem.  Renaming, too.

For those that haven't followed the history, this issue started as a result of the fix to rhbz 885288 aka CVE-2014-3215.  If you work around it by downgrading libcap-ng, then you have a working selinux sandbox but you're also vulnerable to a privilege escalation attack.

Comment 36 Miroslav Grepl 2015-03-06 09:43:58 UTC
Ok we have bounded transitions here and we need to make sandbox working with it.

Comment 37 Joachim Frieben 2015-03-07 06:14:06 UTC
Description of problem:
I ran 'sandbox -X evince'.

Version-Release number of selected component:
selinux-policy-3.13.1-105.3.fc21.noarch

Additional info:
reporter:       libreport-2.3.0
hashmarkername: setroubleshoot
kernel:         3.18.7-200.fc21.x86_64
type:           libreport

Comment 38 Joachim Frieben 2015-03-24 21:44:10 UTC
Description of problem:
I ran 'sandbox -X xterm'.

Version-Release number of selected component:
selinux-policy-3.13.1-105.6.fc21.noarch

Additional info:
reporter:       libreport-2.3.0
hashmarkername: setroubleshoot
kernel:         3.19.1-201.fc21.x86_64
type:           libreport

Comment 39 Marian Csontos 2015-03-26 12:25:44 UTC
Still the issue on F22 Beta TC4:

kernel-4.0.0-0.rc3.git0.1.fc22.x86_64
selinux-policy-targeted-3.13.1-116.fc22.noarch

Andy, the kernel already has the patch from comment 21. Are there changes to policy necessary?

What are our current options?

- use VMs (memory/CPU intensive)
- use an old version of libcap-ng

Is there any better option at the moment?

/me wonders what's Dan Walsh using instead...

Comment 40 Stephen Smalley 2015-03-26 13:20:29 UTC
Requires a policy change to use typebounds and ensure that the new domain is strictly bounded by the parent.  Fedora policy spec file has SEMOD_EXP="/usr/bin/semodule_expand -a" which disables build-time validation; please remove.  Also would be nice to re-enable expand-check=1 in /etc/selinux/semanage.conf in Fedora (neverallow check time significantly improved if using libsepol 2.4).

Comment 41 Andy Lutomirski 2015-03-26 14:56:56 UTC
As far as I know, all this needs is to do what Stephen just described.  My grasp of the policy language is pretty bad, though, so I really don't want to make the policy change myself.

Comment 42 Marian Csontos 2015-03-26 15:18:30 UTC
Peter, any chance getting this into F22? Seems GNOME application sandboxes are still far away, and this may be the only sane way at the moment.

Comment 43 Miroslav Grepl 2015-03-30 19:23:51 UTC
Trying to make this working. We can get proper transitions wit rules like

typebounds sandbox_web_t sandbox_xserver_t;

but it means we still need to define

allow sandbox_web_t xserver_t:unix_stream_socket connectto;

=> bounding domains still require some additional rules because of typebounds. 

It is much more complicated without CIL. I mean these subset rules.

Comment 44 Miroslav Grepl 2015-03-30 20:45:28 UTC
And bigger issue is with

typebounds staff_seunshare_t staff_t;

Comment 45 Stephen Smalley 2015-03-31 14:14:26 UTC
If you have problems with typebounds, take it to the selinux list.
There has been some prior discussion on whether the current logic is correct/optimal, e.g. see:
http://marc.info/?t=142627079300007&r=1&w=2

Comment 46 Lukas Vrabec 2015-04-20 11:08:22 UTC
*** Bug 1212984 has been marked as a duplicate of this bug. ***

Comment 47 Miroslav Grepl 2015-04-27 17:07:17 UTC
Not sure if it is typebounds issue or sandbox issue. Playing with CIL to see if I am able to make it working.

Comment 48 Konstantin Ryabitsev 2015-07-11 18:41:59 UTC
Discouraging to see sandbox still unusable in Fedora, especially after a spate of 0-day flash issues. :(

Comment 49 Miroslav Grepl 2015-08-28 11:37:28 UTC
We have some fixes in F22/F23 Fedora SELinux policy to make "sandbox -X" working with a single type. Basically it allows to run "sandbox -X" in enforcing mode and turn benefits of name spacing on. In Fedora 23, it should be also working with Python 3. 

Another problem is sandbox+typebounds. Basically it can not be working with the current sandbox concept where more types are bounded to the same parent. There we should think about a new client-server architecture for example.

I am moving this bug to rawhide as RFE since we should have sandbox working in F22/F23 how I described above. If not, please add a comment here.

Comment 50 Šimon Lukašík 2015-08-28 12:16:10 UTC
This is great achievement.

Thank You Miroslav & Petr!

Comment 51 Stephen Smalley 2015-08-28 14:29:17 UTC
Can you clarify why typebounds cannot be used with the current sandbox?  Feel free to take it up on selinux@tycho.nsa.gov list.

Comment 52 Miroslav Grepl 2015-08-30 21:05:48 UTC
(In reply to Stephen Smalley from comment #51)
> Can you clarify why typebounds cannot be used with the current sandbox? 
> Feel free to take it up on selinux@tycho.nsa.gov list.

Sure, the problem is with the following use cases:

$ sandbox -X -t sandbox_web_t firefox

needs to have

(typebounds sandbox_web_t sandbox_xserver_t)
(typebounds sandbox_web_t sandbox_web_client_t)

to reach expected functionality


 |  |  `-sandbox(`staff_u:staff_r:staff_t:s0-s0:c0.c1023')
 |  |     |  `-sandboxX.sh(`staff_u:staff_r:sandbox_web_t:s0:c328,c845')
 |  |     |     |-Xephyr(`staff_u:staff_r:sandbox_xserver_t:s0:c328,c845')

..

 |  |     |  `-sandboxX.sh(`staff_u:staff_r:sandbox_web_t:s0:c328,c845')
 |  |     |    `-start(`staff_u:staff_r:sandbox_web_client_t:s0:c328,c845')


But you can call it also for another types:

$ sandbox -X -t sandbox_net_t firefox 

and it needs to have

(typebounds sandbox_net_t sandbox_xserver_t)
(typebounds sandbox_net_t sandbox_web_client_t)

and there is a conflict.

# semodule -i mysandbox.cil

Type sandbox_xserver_t already bound by parent at line 46 of /var/lib/selinux/targeted/tmp/modules/100/sandboxX/cil
Now being bound to parent sandbox_web_t at line 8 of /var/lib/selinux/targeted/tmp/modules/400/mysandbox/cil
Bad bounds statement at line 8 of /var/lib/selinux/targeted/tmp/modules/400/mysandbox/cil
Failed to resolve typebounds statement at 8 of /var/lib/selinux/targeted/tmp/modules/400/mysandbox/cil
Failed to resolve ast
semodule:  Failed!

Comment 53 Stephen Smalley 2015-08-31 13:53:46 UTC
Ok, so this is a limitation of typebounds, i.e. that a type can only be bounded by a single other type.  You could of course define separate sandbox_web_xserver_t vs sandbox_net_xserver_t types, each bounded by their respective parent domains (i.e. typebounds sandbox_web_t sandbox_web_xserver_t; typebounds sandbox_net_t sandbox_net_xserver_t;) and likewise for the client types, and set up domain transitions to the right child type for each.  Not sure how difficult that would be, but it could certainly be macroized.

Comment 54 Paul Moore 2015-08-31 18:23:52 UTC
I'm starting to think the allowing bounded domain transitions inside the sandbox tool is always going to be problematic.  I think it is good that we support it for those that want to make use of it (this should be easier to customize now with CIL, yes?), but I think providing a set of bounded domains in the default Fedora policy is always going to be a losing battle.

Comment 55 Andy Lutomirski 2015-08-31 18:52:01 UTC
Given how much of a mess this has been, I'm starting to wonder if the right way to fix this is to switch to a namespace-based approach instead of trying to use SELinux to build the sandbox.  Both mbox and firejail take this approach, although I haven't used either.  Sandstorm works great (disclaimer: I helped write its sandbox), but it's not even close to being usable as a selinux sandbox replacement.

Comment 56 Stephen Smalley 2015-08-31 19:13:28 UTC
(In reply to Paul Moore from comment #54)
> I'm starting to think the allowing bounded domain transitions inside the
> sandbox tool is always going to be problematic.  I think it is good that we
> support it for those that want to make use of it (this should be easier to
> customize now with CIL, yes?), but I think providing a set of bounded
> domains in the default Fedora policy is always going to be a losing battle.

I don't think it is unachievable given the small number of discrete sandbox domains.  I'm not even sure if we truly need all of the different sandbox types that are defined today (if the user has to manually specify one via -t, then I think you've already failed usability).  But running the nested X server (Xephyr) in a separate domain from the X application is useful for security, so supporting that domain transition through appropriate definitions of bounded types seems worthwhile to me.

Comment 57 Paul Moore 2015-08-31 19:52:02 UTC
(In reply to Andy Lutomirski from comment #55)
> Given how much of a mess this has been, I'm starting to wonder if the right
> way to fix this is to switch to a namespace-based approach instead of trying
> to use SELinux to build the sandbox.  Both mbox and firejail take this
> approach, although I haven't used either.  Sandstorm works great
> (disclaimer: I helped write its sandbox), but it's not even close to being
> usable as a selinux sandbox replacement.

I suspect at some point in the future we will probably end up with something that is Docker based, but I'd still like to fix the SELinux sandbox in its current form.

Comment 58 Daniel Walsh 2015-09-01 11:43:17 UTC
xdg-app is probably the future not Docker.

selinux sandbox uses namespaces and SELinux and I suspect in the future we will do the same.

Comment 59 Florian Weimer 2015-09-01 11:46:59 UTC
(In reply to Daniel Walsh from comment #58)
> xdg-app is probably the future not Docker.

xdg-app does not sandbox access to the display hardware, so it sidesteps this issue.

Comment 60 Daniel Walsh 2015-09-01 12:28:54 UTC
We have not added security to xdg-app yet, we need wayland to have a good experience with this.   But that is the future.

Comment 61 Miroslav Grepl 2015-09-01 13:45:01 UTC
(In reply to Stephen Smalley from comment #53)
> Ok, so this is a limitation of typebounds, i.e. that a type can only be
> bounded by a single other type.  You could of course define separate
> sandbox_web_xserver_t vs sandbox_net_xserver_t types, each bounded by their
> respective parent domains (i.e. typebounds sandbox_web_t
> sandbox_web_xserver_t; typebounds sandbox_net_t sandbox_net_xserver_t;) and
> likewise for the client types, and set up domain transitions to the right
> child type for each.  Not sure how difficult that would be, but it could
> certainly be macroized.

Yes, I agree with you that we could try to go this way.

Comment 62 Patrick C. F. Ernzer 2015-10-29 13:34:13 UTC
JFYI; sandbox works again for me (tested with my main usecase for this tool; opening a sandboxed firefox)

$ getenforce 
Enforcing
$ rpm -q policycoreutils-sandbox
policycoreutils-sandbox-2.3-18.fc22.x86_64
$ sandbox -t sandbox_web_t -w 900x690 -X firefox 'http://www.redhat.com/'

works as expected. Thank you for the fix!

Comment 63 Dimitris 2015-10-29 16:07:10 UTC
(In reply to Patrick C. F. Ernzer from comment #62)
> JFYI; sandbox works again for me (tested with my main usecase for this tool;
> opening a sandboxed firefox)

Doesn't work here:

$ getenforce 
Enforcing
$ rpm -q policycoreutils-sandbox
policycoreutils-sandbox-2.3-18.fc22.x86_64
$ sandbox -t sandbox_web_t -w 900x690 -X firefox 'http://www.redhat.com/'

results in

SELinux is preventing /usr/bin/Xephyr from connectto access on the unix_stream_socket @/tmp/.X11-unix/X0.

Comment 64 Stephen Smalley 2015-10-29 17:41:20 UTC
(In reply to Dimitris from comment #63)
> (In reply to Patrick C. F. Ernzer from comment #62)
> > JFYI; sandbox works again for me (tested with my main usecase for this tool;
> > opening a sandboxed firefox)
> 
> Doesn't work here:
> 
> $ getenforce 
> Enforcing
> $ rpm -q policycoreutils-sandbox
> policycoreutils-sandbox-2.3-18.fc22.x86_64
> $ sandbox -t sandbox_web_t -w 900x690 -X firefox 'http://www.redhat.com/'
> 
> results in
> 
> SELinux is preventing /usr/bin/Xephyr from connectto access on the
> unix_stream_socket @/tmp/.X11-unix/X0.

Make sure your selinux-policy-targeted is up-to-date.

Comment 65 Dimitris 2015-10-29 17:47:50 UTC
In the meantime I switched to the new F23 laptop.  sandbox now works:

$ rpm -q policycoreutils-sandbox
policycoreutils-sandbox-2.4-14.fc23.x86_64
$ getenforce 
Enforcing
$ sandbox -t sandbox_web_t -w 900x690 -X firefox 'http://www.redhat.com/'

browser comes up but I also get this:

Raw Audit Messages
type=AVC msg=audit(1446140628.631:813): avc:  denied  { connectto } for  pid=13846 comm="dbus-daemon" path="/run/systemd/journal/stdout" scontext=unconfined_u:unconfined_r:sandbox_web_t:s0:c500,c973 tcontext=system_u:system_r:kernel_t:s0 tclass=unix_stream_socket permissive=0

Comment 66 Jan Kurik 2016-02-24 13:15:22 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

Comment 67 Alphonse Steiner 2016-06-27 15:58:44 UTC
Everything worked fine in fedora 23, but it is broken again in fedora 24...

First, I need to set the '-d 96' option to avoid the error:
-------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/bin/sandbox", line 514, in <module>
    rc = sandbox.main()
  File "/usr/bin/sandbox", line 502, in main
    return self.__execute()
  File "/usr/bin/sandbox", line 454, in __execute
    import gtk
ImportError: No module named 'gtk'
-------------------------------------------------------------


With this option set, I can see briefly the window frame before it disappears.
The audit log shows:
-------------------------------------------------------------
type=SELINUX_ERR msg=audit(1467042404.463:4963): op=security_bounded_transition seresult=denied oldcontext=staff_u:staff_r:sandbox_web_t:s0:c109,c1023 newcontext=staff_u:staff_r:sandbox_xserver_t:s0:c109,c1023
type=SELINUX_ERR msg=audit(1467042404.755:4964): op=security_bounded_transition seresult=denied oldcontext=staff_u:staff_r:sandbox_web_t:s0:c109,c1023 newcontext=staff_u:staff_r:sandbox_web_client_t:s0:c109,c1023
type=SELINUX_ERR msg=audit(1467042404.847:4965): op=security_bounded_transition seresult=denied oldcontext=staff_u:staff_r:staff_seunshare_t:s0-s0:c0.c1023 newcontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023
type=SELINUX_ERR msg=audit(1467042404.868:4966): op=security_bounded_transition seresult=denied oldcontext=staff_u:staff_r:staff_seunshare_t:s0-s0:c0.c1023 newcontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023
type=SELINUX_ERR msg=audit(1467042404.874:4967): op=security_bounded_transition seresult=denied oldcontext=staff_u:staff_r:staff_seunshare_t:s0-s0:c0.c1023 newcontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023
-------------------------------------------------------------

I have tried to add the policy:
(typebounds sandbox_web_t sandbox_xserver_t)
(typebounds sandbox_web_t sandbox_web_client_t)


but then the log reports:
-------------------------------------------------------------
type=SELINUX_ERR msg=audit(1467041652.116:4954): op=security_compute_av reason=bounds scontext=staff_u:staff_r:sandbox_web_t:s0:c462,c664 tcontext=staff_u:staff_r:sandbox_xserver_t:s0:c462,c664 tclass=process perms=transition
type=AVC msg=audit(1467041652.116:4955): avc:  denied  { transition } for  pid=20174 comm="sandboxX.sh" path="/usr/bin/Xephyr" dev="dm-0" ino=962641 scontext=staff_u:staff_r:sandbox_web_t:s0:c462,c664 tcontext=staff_u:staff_r:sandbox_xserver_t:s0:c462,c664 tclass=process permissive=0
type=SELINUX_ERR msg=audit(1467041652.133:4956): op=security_bounded_transition seresult=denied oldcontext=staff_u:staff_r:staff_seunshare_t:s0-s0:c0.c1023 newcontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023
type=SELINUX_ERR msg=audit(1467041652.148:4957): op=security_bounded_transition seresult=denied oldcontext=staff_u:staff_r:staff_seunshare_t:s0-s0:c0.c1023 newcontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023
type=SELINUX_ERR msg=audit(1467041652.154:4958): op=security_bounded_transition seresult=denied oldcontext=staff_u:staff_r:staff_seunshare_t:s0-s0:c0.c1023 newcontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023
-------------------------------------------------------------

Can someone explain what happened and fix it?

Comment 68 Petr Lautrbach 2016-06-27 16:18:21 UTC
(In reply to Alphonse Steiner from comment #67)
> Everything worked fine in fedora 23, but it is broken again in fedora 24...
> 
> First, I need to set the '-d 96' option to avoid the error:
> -------------------------------------------------------------
> Traceback (most recent call last):
>   File "/usr/bin/sandbox", line 514, in <module>
>     rc = sandbox.main()
>   File "/usr/bin/sandbox", line 502, in main
>     return self.__execute()
>   File "/usr/bin/sandbox", line 454, in __execute
>     import gtk
> ImportError: No module named 'gtk'
> -------------------------------------------------------------

This is already fixed in Rawhide and I'll push an update to Fedora 24 soon.

Comment 69 Timo Trinks 2016-07-14 04:53:15 UTC
Hi Petr - any ETA when you'll push this to the updates for Fedora 24? Being able to sandbox Firefox has been a pretty useful feature up until recently. Thanks, Timo

Comment 70 Fedora Update System 2016-07-15 11:54:05 UTC
checkpolicy-2.5-6.fc24, libselinux-2.5-9.fc24, libsemanage-2.5-5.fc24, libsepol-2.5-8.fc24, policycoreutils-2.5-12.fc24, secilc-2.5-4.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-84d1f77e58

Comment 71 Alphonse Steiner 2016-07-15 14:00:10 UTC
Good point: the gtk part is fixed!
Bad point: the sandbox is still broken. Here is the log:

=============================================================================
type=SELINUX_ERR msg=audit(1468590543.030:801): op=security_bounded_transition seresult=denied oldcontext=staff_u:staff_r:sandbox_web_t:s0:c378,c750 newcontext=staff_u:staff_r:sandbox_xserver_t:s0:c378,c750
type=AVC msg=audit(1468590543.069:802): avc:  denied  { unix_read } for  pid=2594 comm="Xwayland" key=0  scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:sandbox_web_t:s0:c378,c750 tclass=shm permissive=0
type=SELINUX_ERR msg=audit(1468590543.246:803): op=security_bounded_transition seresult=denied oldcontext=staff_u:staff_r:sandbox_web_t:s0:c378,c750 newcontext=staff_u:staff_r:sandbox_web_client_t:s0:c378,c750
type=SELINUX_ERR msg=audit(1468590543.420:804): op=security_bounded_transition seresult=denied oldcontext=staff_u:staff_r:staff_seunshare_t:s0-s0:c0.c1023 newcontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023
type=SELINUX_ERR msg=audit(1468590543.437:805): op=security_bounded_transition seresult=denied oldcontext=staff_u:staff_r:staff_seunshare_t:s0-s0:c0.c1023 newcontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023
type=SELINUX_ERR msg=audit(1468590543.446:806): op=security_bounded_transition seresult=denied oldcontext=staff_u:staff_r:staff_seunshare_t:s0-s0:c0.c1023 newcontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023
=============================================================================

Note: the command used was 'sandbox -X -t sandbox_web_t -w 1248x1024  -- gnome-terminal' on gnome-wayland.

Comment 72 Joachim Frieben 2016-07-17 07:26:40 UTC
(In reply to Fedora Update System from comment #70)
Command 'sandbox -X ..' is still broken:

/usr/bin/sandbox:454: PyGIWarning: Gtk was imported without specifying a version first. Use gi.require_version('Gtk', '3.0') before import to ensure that the right version gets loaded.
  from gi.repository import Gtk

Comment 73 Fedora Update System 2016-07-20 00:20:36 UTC
checkpolicy-2.5-6.fc24, libselinux-2.5-9.fc24, libsemanage-2.5-5.fc24, libsepol-2.5-8.fc24, policycoreutils-2.5-12.fc24, secilc-2.5-4.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Comment 74 Joachim Frieben 2016-07-20 07:18:21 UTC
(In reply to Joachim Frieben from comment #72)
Issue has been reported in new bug 1358138.


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