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>
Mention how to format capabilities for --add-cap, e.g.
CAP_DAC_READ_SEARCH instead of DAC_READ_SEARCH.
Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
load_file_data() closes the passed file descriptor in case of an read(2)
failure. The file descriptor is however owned by the caller and should
not be closed to avoid a double-close.
Since in this error branch NULL is always returned the only affected
caller is load_file_data(), as all other callers immediately abort via
die_with_error(). As bubblewrap is single-threaded the second close(2)
in load_file_data() will be well-defined and fail with EBADF, leading to
no unrelated file descriptor to be closed
Found by GCC analyzer:
./utils.c: In function ‘load_file_at’:
./utils.c:630:3: warning: double ‘close’ of file descriptor ‘fd’ [CWE-1341] [-Wanalyzer-fd-double-close]
630 | close (fd);
| ^~~~~~~~~~
...
| 596 | close (fd);
| | ~~~~~~~~~~
| | |
| | (15) first ‘close’ here
...
| 630 | close (fd);
| | ~~~~~~~~~~
| | |
| | (20) second ‘close’ here; first ‘close’ was at (15)
Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
General-purpose desktop distributions are compiled with CONFIG_SECCOMP
and CONFIG_SECCOMP_FILTER, but vendor kernels for phones and other
assorted embedded devices don't necessarily enable these options. These
kernels are unsuitable for running Flatpak, or anything else that relies
on `bwrap --seccomp` or `bwrap --add-seccomp-fd`.
Missing CONFIG_SECCOMP or CONFIG_SECCOMP_FILTER is not the *only* reason
why we could get EINVAL here: I think we'd also get EINVAL if the seccomp
program is syntatically invalid. However, it's a relatively likely reason,
so it seems worth providing a hint.
Helps: flatpak/flatpak#3069
Signed-off-by: Simon McVittie <smcv@collabora.com>
Older versions of capsh would only show the capabilities, which we
expect not to change when we don't drop capabilities; but newer
versions also display whether the NO_NEW_PRIVS bit is set, and we *do*
expect to change that.
Resolves: https://github.com/containers/bubblewrap/issues/544
Signed-off-by: Simon McVittie <smcv@collabora.com>
We can't combine --disable-userns with entering an existing user
namespace via --userns if the existing user namespace was created with
--disable-userns, because its ability to create nested user namespaces
has already been disabled. However, the next best thing is to verify
that we are already in the desired state.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Some use-cases of bubblewrap want to ensure that the subprocess can't
further re-arrange the filesystem namespace, or do other more complex
namespace modification. For example, Flatpak wants to prevent sandboxed
processes from altering their /proc/$pid/root/.flatpak-info, so that
/.flatpak-info can safely be used as an indicator that a process is part
of a Flatpak app.
This approach was suggested by lukts30 on containers/bubblewrap#452.
The sysctl-controlled maximum numbers of namespaces are themselves
namespaced, so we can disable nested user namespaces by setting the
limit to 1 and then entering a new, nested user namespace. The resulting
process loses its privileges in the namespace where the limit was set
to 1, so it is unable to move the limit back up.
Co-authored-by: Alexander Larsson <alexl@redhat.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
df --output was new in coreutils 8.21 (2013), and non-GNU
implementations like busybox df don't have it.
This avoids a test failure in Steam Runtime 1 'scout', which is based
on Ubuntu 12.04 (2012). It'll also be helpful for anyone maintaining
an OS with non-GNU shell utilities.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Prompted by flatpak/flatpak#4731, in which a misconfigured SMB automount
was failing to be remounted with ENODEV. This would have been easier to
debug if we knew which path could not be remounted.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is useful when building a self-contained, relocatable tree
containing a build of bubblewrap and all of its non-glibc dependencies
(in practice this means libcap and maybe libselinux), as is done in
the Steam container runtime. A RPATH/RUNPATH pointing to ${ORIGIN}/../lib
allows bwrap to find an adjacent, bundled copy of libcap.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The goal of this assertion was to demonstrate that a setuid bwrap does
not give us access to otherwise unreadable files, but if we want to
check that, we should probably be looking at the bind-mount destination
instead of the source file.
Leave the old assertion in too, just in case *that* fails.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Ordinarily, we would not be able to read /etc/shadow if we're not uid 0;
but when building in a sysroot owned by the current user (for example
by setting it up using bwrap, as steam-runtime-tools does), we might
actually be able to read it. Skip the assertion that we cannot read it
in this case.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we don't do this, AddressSanitizer busy-loops with this backtrace:
#0 in sched_yield
#1 in __sanitizer::StopTheWorld
#2 in __lsan::LockStuffAndStopTheWorldCallback
#3 in __GI___dl_iterate_phdr
#4 in __lsan::LockStuffAndStopTheWorld
#5 in __lsan::CheckForLeaks
#6 in __lsan::DoLeakCheck
#7 __lsan::DoLeakCheck
#8 in __cxa_finalize
#9 in __do_global_dtors_aux
#10 in ??
#11 in _dl_fini
This fixes the hang described in commit 2e3d6e7d, so remove the
workarounds from that commit.
Signed-off-by: Simon McVittie <smcv@collabora.com>
gcc's AddressSanitizer makes system calls that our filter doesn't
allow for, resulting in a fatal error when run under a restrictive
seccomp filter.
try-syscall is a helper for the test, rather than being code under test
itself, so we don't really need this instrumentation in it: all we want
it to do is make some specific syscalls.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This follows the usual feature semantics: they're mandatory if the
feature is enabled, aren't checked if the feature is disabled, and are
optional if the feature is in the auto state (which is the default for
this particular feature).
The logic used here is similar to AX_CHECK_DOCBOOK_XSLT in
autoconf-archive.
Resolves: https://github.com/containers/bubblewrap/issues/500
Signed-off-by: Simon McVittie <smcv@collabora.com>
