diff options
| -rw-r--r-- | README.md | 25 | ||||
| -rw-r--r-- | SECURITY.md | 39 |
2 files changed, 62 insertions, 2 deletions
@@ -35,8 +35,8 @@ The original bubblewrap code existed before user namespaces - it inherits code f which in turn distantly derives from [linux-user-chroot](https://git.gnome.org/browse/linux-user-chroot). -Security --------- +System security +--------------- The maintainers of this tool believe that it does not, even when used in combination with typical software installed on that distribution, @@ -47,6 +47,27 @@ In particular, bubblewrap uses `PR_SET_NO_NEW_PRIVS` to turn off setuid binaries, which is the [traditional way](https://en.wikipedia.org/wiki/Chroot#Limitations) to get out of things like chroots. +Sandbox security +---------------- + +bubblewrap is a tool for constructing sandbox environments. +bubblewrap is not a complete, ready-made sandbox with a specific security +policy. + +Some of bubblewrap's use-cases want a security boundary between the sandbox +and the real system; other use-cases want the ability to change the layout of +the filesystem for processes inside the sandbox, but do not aim to be a +security boundary. +As a result, the level of protection between the sandboxed processes and +the host system is entirely determined by the arguments passed to +bubblewrap. + +Whatever program constructs the command-line arguments for bubblewrap +(often a larger framework like Flatpak, libgnome-desktop, sandwine +or an ad-hoc script) is responsible for defining its own security model, +and choosing appropriate bubblewrap command-line arguments to implement +that security model. + Users ----- diff --git a/SECURITY.md b/SECURITY.md index d914d4a..0ddfc6c 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,3 +1,42 @@ ## Security and Disclosure Information Policy for the bubblewrap Project The bubblewrap Project follows the [Security and Disclosure Information Policy](https://github.com/containers/common/blob/HEAD/SECURITY.md) for the Containers Projects. + +### System security + +If bubblewrap is setuid root, then the goal is that it does not allow +a malicious local user to do anything that would not have been possible +on a kernel that allows unprivileged users to create new user namespaces. +For example, [CVE-2020-5291](https://github.com/containers/bubblewrap/security/advisories/GHSA-j2qp-rvxj-43vj) +was treated as a security vulnerability in bubblewrap. + +If bubblewrap is not setuid root, then it is not a security boundary +between the user and the OS, because anything bubblewrap could do, a +malicious user could equally well do by writing their own tool equivalent +to bubblewrap. + +### Sandbox security + +bubblewrap is a toolkit for constructing sandbox environments. +bubblewrap is not a complete, ready-made sandbox with a specific security +policy. + +Some of bubblewrap's use-cases want a security boundary between the sandbox +and the real system; other use-cases want the ability to change the layout of +the filesystem for processes inside the sandbox, but do not aim to be a +security boundary. +As a result, the level of protection between the sandboxed processes and +the host system is entirely determined by the arguments passed to +bubblewrap. + +Whatever program constructs the command-line arguments for bubblewrap +(often a larger framework like Flatpak, libgnome-desktop, sandwine +or an ad-hoc script) is responsible for defining its own security model, +and choosing appropriate bubblewrap command-line arguments to implement +that security model. + +For example, +[CVE-2017-5226](https://github.com/flatpak/flatpak/security/advisories/GHSA-7gfv-rvfx-h87x) +(in which a Flatpak app could send input to a parent terminal using the +`TIOCSTI` ioctl) is considered to be a Flatpak vulnerability, not a +bubblewrap vulnerability. |