From 795eeee77eab88afb9db27b06e1d23cc3aebe38e Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Thu, 2 Mar 2023 17:12:03 +0000 Subject: [PATCH] README, SECURITY: Clarify that bubblewrap does not define a security model bubblewrap can provide a robust security boundary that severely limits functionality, or it can provide full functionality without any attempt at being a security boundary, or anything in between those extremes. If a caller of bubblewrap chooses inappropriate command-line arguments for their desired security model, then bubblewrap will not provide the security model they are aiming for, but this is not a bubblewrap vulnerability. Apparently this isn't clear to everyone, so try to clarify. The one place where bubblewrap *does* define some sort of security policy for itself is when it's setuid root, in which case it's responsible for preventing users from carrying out privilege escalation attacks like CVE-2020-5291. Resolves: https://github.com/containers/bubblewrap/issues/555 Signed-off-by: Simon McVittie --- README.md | 25 +++++++++++++++++++++++-- SECURITY.md | 39 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 62 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index d251fbdb..4a5cdbf7 100644 --- a/README.md +++ b/README.md @@ -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 d914d4af..0ddfc6c8 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.