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 <smcv@collabora.com>

2 files changed, 62 insertions, 2 deletions

diff --git a/README.md b/README.md
index d251fbd..4a5cdbf 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 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.