[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 21 Apr 2024 13:00:18 +0100
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: Linux: Disabling network namespaces
On Sat, 20 Apr 2024 at 21:33:07 +0000, Jordan Glover wrote:
> On Saturday, April 20th, 2024 at 8:12 PM, Solar Designer <solar@...nwall.com> wrote:
> > Does bubblewrap maybe already relinquish also the ability to create
> > nested namespaces, which it probably could do with seccomp?
bubblewrap doesn't rely on seccomp itself, because linking to libseccomp
and compiling seccomp programs would be a concerning amount of attack
surface for a program that is optionally setuid root, but it has options
that can be used to make it receive a precompiled seccomp program as a
binary blob and submit it to the kernel. The intention is that a larger
framework like Flatpak, WebKitGTK or similar, which isn't setuid, can
supply a seccomp program if it wants to.
The design of bubblewrap is that it's a toolkit for making sandboxes,
but is not, itself, a ready-made sandboxing solution - so the sandbox can
be secure but limited, insecure but versatile, or anywhere in between,
and larger frameworks like Flatpak are responsible for designing their
own security model and constructing a bubblewrap command-line that will
implement it.
> bubblwrap has --disable-userns option
...
> Flatpak uses this (or seccomp filter) to block nested namespaces
Development versions of Flatpak (1.15.6+) use both seccomp and
--disable-userns: possibly redundant, but it's better to be safe,
and Flatpak wants to disable some other syscalls with seccomp anyway
(for example access to the kernel keyring).
Older versions of Flatpak completely relied on seccomp, because
--disable-userns is a recent addition to bubblewrap.
bubblewrap also uses PR_SET_NO_NEW_PRIVS (this is hard-coded and not
optional), but creating a new user namespace in which you have all
capabilities is not considered to be a new privilege for the purposes
of that prctl, so that doesn't help us here.
> For this reason firefox own sandbox doesn't use namespaces in flatpak
Flatpak does have a feature (the somewhat misleadingly named
"sub-sandboxes") where a sandboxed program can ask Flatpak to create a
new user namespace on its behalf, in parallel with the one it uses for
the original program. This can either be done with the same restrictions
as the original program and therefore no effective security boundary
between the original program and the sub-sandbox (Steam does this, to
run parts of itself with a different /usr), or with tighter restrictions
(the original purpose of this feature).
But, as noted on the Firefox bug, this implies some IPC, a new user
namespace and an execve(), so it's higher-overhead than just fork()ing:
if the original program wants to share state with the new program,
it needs to do that explicitly, perhaps by using shared memory or an
AF_UNIX-based protocol like D-Bus. A stronger security boundary means
more effort needs to be put into crossing that boundary safely and with
the desired performance characteristics, so t's a trade-off with no
single correct answer.
smcv
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
