Date: Thu, 13 Oct 2016 11:10:19 +0100 From: Simon McVittie <smcv@...ian.org> To: oss-security@...ts.openwall.com Subject: Re: bubblewrap LPE On Wed, 12 Oct 2016 at 15:12:47 +0200, Sebastian Krahmer wrote: > /usr/bin/bwrap may be installed mode 04755 or with cap_sys_admin and other > file caps. I dont know if there are any dists already shipping it that way, > but the Makefile and some RedHat spec files contain file caps for it. It needs to be setuid root (or CAP_SYS_ADMIN, which might as well be setuid root) to be useful on any distribution whose kernel doesn't normally allow unprivileged users to open user-namespaces; in particular, Debian, RHEL, and backports to older/LTS Ubuntu (but not current Ubuntu). > For some reason it sets the PR_SET_DUMPABLE flag, as seen below. The comment about > it looks strange to me. If thats really true, suid programs shouldn't > be forced to play with the dumpable flag to achieve their goal. I assume the developers of Bubblewrap wouldn't have done this if the kernel (or at least *a* kernel they care about) didn't require it. But hopefully becoming dumpable can be restricted to smaller sections of the code. If it's only for write_uid_gid_map(), then one way would be for that function to fork(), with the child making itself dumpable and writing the map files, and the parent just waiting for the child? > Once the dumpable flag is set, there is a chance we could attach to the process, > once the remaining caps are dropped and the whole process runs as user. I have reported this to <https://github.com/projectatomic/bubblewrap/issues/107>. I believe the intention is that none of the operations that can pass over the privilege separation socket are problematic, because they only affect the sandboxed processes, and if you can ptrace bwrap then you can certainly ptrace and subvert the sandboxed processes too. SETUP_SET_HOSTNAME clearly doesn't match that intention, *if* Bubblewrap didn't unshare the UTS namespace beforehand; Bubblewrap does insist that --hostname can't be used without --unshare-uts, but you're right that a user outside the sandbox can ptrace it and bypass that check by making it behave as though --hostname had been used. As a quick temporary fix for Debian, I'm reverting the addition of SETUP_SET_HOSTNAME. Am I right in thinking that this pseudocode would fix it while reinstating the feature? case PRIV_SEP_OP_SET_HOSTNAME: if (!opt_unshare_uts) die_with_error ("Refusing to set hostname in original namespace"); else if (!sethostname (... as before)) die_with_error (... as before); Thanks, S
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ