-
-
v0.1.75dec838b · ·
Release 0.1.7 (CVE-2017-5226) This release backs out the change in 0.1.6 which unconditionally called setsid() in order to fix a security issue with `TIOCSTI`, aka CVE-2017-522. That change caused some behavioural issues that are hard to work with in some cases. For instance, it makes shell job control not work for the bwrap command. Instead there is now a new option --new-session which works like 0.1.6. It is recommended that you use this if possible, but if not we recommended that you neutralize this some other way, for instance using SECCOMP, which is what flatpak does: https://github.com/flatpak/flatpak/commit/902fb713990a8f968ea4350c7c2a27ff46f1a6c4 In order to make it easy to create maximally safe sandboxes we have also added a new commandline switch called --unshare-all. It unshares all possible namespaces and is currently equivalent with: --unshare-user-try --unshare-ipc --unshare-pid --unshare-net \ --unshare-uts --unshare-cgroup-try However, the intent is that as new namespaces are added to the kernel they will be added to this list. Additionally, if --share-net is specified the network namespace is *not* unshared. This release also has some bugfixes: * bwrap reaps (unexpected) children that are inherited from the parent, something which can happen if bwrap is part of a shell pipeline. * bwrap clears the capability bounding set. The permitted capabilities was already empty, and use of PR_NO_NEW_PRIVS should make it impossible to increase the capabilities, but more layers of protection is better. * The seccomp filter is now installed at the very end of bwrap, which means the requirement of the filter is minimal. Any bwrap seccomp filter must at least allow: execve, waitpid and write Git-EVTag-v0-SHA512: 5794231c542988f81e628786383e91dc44d5bd5a9cf816f11cc3a34cbb6eb511b14f945c28d14e1f78babf4f02543f13b199d16e90b3aa8e7a8270daf4be486d
-
-
v0.1.69f6076dd · ·
Release 0.1.6 (CVE-2017-5226) This fixes a security issue with `TIOCSTI`, aka CVE-2017-522. Note bubblewrap is far from the only program that has this issue, and I think the best fix is probably in the kernel to support disabling this ioctl. Programs can also work around this by calling `setsid()` on their own in an exec handler before doing an `exevp("bwrap")`. Git-EVTag-v0-SHA512: aea2bc21fa6194f7d5c4eaf7294dd35e4434616678d2f79c1e9044aca063bf77db199b1030628ced2eb7d3a33d6a6419047e32ea7891be396d9ddb50a7b1f745
-
-
v0.1.5a10af855 · ·
Release 0.1.5 This is a bugfix release, here are the major changes: * Running bubblewrap as root now works again * Various fixes for the testsuite * Use same default compiler warnings as ostree * Handle errors resolving symlinks during bind mounts Git-EVTag-v0-SHA512: ea9673ef5b2df92a216da69ef5589dfd465175bc56feedafd126d0ab2e40f3183974de2c67c92f96470c749f91d4f9f55483cea54030cf35890ed4de18ca952f
-
-
v0.1.459f89470 · ·
Release 0.1.4 This release contains a workaround for the kernel allowing the user to ptrace any process in the child user namespace. Prior to this workaround the user could attach to the setup code in bubblewrap and take control while the child still had full privileges in the user namespace (it could never get more privileges in the parent namespace though). With the workaround, we're now true to the README in that bubblewrap only allows a subset of the user namespace features. In order to fix the above we had to drop the support for a set-caps binary. We now only support setuid 0 (or unprivileged if the kernel has such user namespace support). Additionally this release fixes the handling of recursive bind mounts flags where previously we sometimes failed to handle some uncommon setups. If you were unable to start bwrap before due to mount errors this should now be fixed. Git-EVTag-v0-SHA512: 55e170e25eee5f3c8eb947c1532bd7d9dffe74277b9964a28b0bc184800da3d904282668ced54a2bff53c3d9811b40435d8b1db30b5eab610fa85a0954ed20bf
-