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>
This commit is contained in:
parent
da63f2bddb
commit
795eeee77e
25
README.md
25
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
|
||||
-----
|
||||
|
||||
|
|
39
SECURITY.md
39
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.
|
||||
|
|
Loading…
Reference in New Issue