Bug 1103622
Summary: | sandbox -X is completely broken | |||
---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Petr Lautrbach <plautrba> | |
Component: | policycoreutils | Assignee: | Petr Lautrbach <plautrba> | |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
Severity: | unspecified | Docs Contact: | ||
Priority: | unspecified | |||
Version: | 24 | CC: | alphsteiner, amessina, aminoiu, amit.shah, aph, bgoncalv, bugzilla, cyrusyzgtt, dimitris, dominick.grift, dwalsh, eparis, fedora, fweimer, icon, jfrieben, jpokorny, kahlil.hodgson, luto, lvrabec, mcsontos, mdavis, mgrepl, mmalik, ollieteasley, pasik, pcfe, plautrba, pmoore, pvrabec, rsawhill, rz, sdsmall, sgrubb, slukasik, ssorce, ttrinks, wdh, wtogami, xtr.xtrnet | |
Target Milestone: | --- | |||
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | policycoreutils-2.5-12.fc24 | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1357115 (view as bug list) | Environment: | ||
Last Closed: | 2016-07-20 00:21:03 UTC | Type: | Bug | |
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: | 1357115 |
Description
Petr Lautrbach
2014-06-02 08:38:17 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. 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? 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 sandbox works using https://kojipkgs.fedoraproject.org//packages/libcap-ng/0.7.4/2.fc21/x86_64/libcap-ng-0.7.4-2.fc21.x86_64.rpm > 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.
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. 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')] 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 ... 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. So we really need a way to tell the kernel that we want transitions to continue to happen but nosuid. (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? *** Bug 1105652 has been marked as a duplicate of this bug. *** *** Bug 1105798 has been marked as a duplicate of this bug. *** 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. 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) 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. 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... 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. subscribe Same problem in Fedora 19 btw. 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. *** Bug 1111109 has been marked as a duplicate of this bug. *** 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). Matthew, so far the only workaround is to downgrade libcap-ng to the one released at F20 GA ... which is less then ideal. 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. 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. 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. 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'. *** Bug 1173590 has been marked as a duplicate of this bug. *** *** Bug 1176022 has been marked as a duplicate of this bug. *** 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. 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.* 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 *** Bug 1093702 has been marked as a duplicate of this bug. *** 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. Ok we have bounded transitions here and we need to make sandbox working with it. 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 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 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... 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). 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. 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. 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. And bigger issue is with typebounds staff_seunshare_t staff_t; 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 *** Bug 1212984 has been marked as a duplicate of this bug. *** Not sure if it is typebounds issue or sandbox issue. Playing with CIL to see if I am able to make it working. Discouraging to see sandbox still unusable in Fedora, especially after a spate of 0-day flash issues. :( 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. This is great achievement. Thank You Miroslav & Petr! Can you clarify why typebounds cannot be used with the current sandbox? Feel free to take it up on selinux.gov list. (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.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! 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. 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. 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. (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. (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. 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. (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. We have not added security to xdg-app yet, we need wayland to have a good experience with this. But that is the future. (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. 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! (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. (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. 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 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 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? (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. 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 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 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. (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 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. (In reply to Joachim Frieben from comment #72) Issue has been reported in new bug 1358138. |