oss-sec mailing list archives
Re: Linux: Disabling network namespaces
From: Simon McVittie <smcv () debian org>
Date: Sun, 21 Apr 2024 13:00:18 +0100
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 () openwall 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
Current thread:
- Re: Linux: Disabling network namespaces, (continued)
- Re: Linux: Disabling network namespaces Solar Designer (Apr 15)
- Re: Linux: Disabling network namespaces Simon McVittie (Apr 15)
- Re: Linux: Disabling network namespaces Jordan Glover (Apr 16)
- Re: Linux: Disabling network namespaces Mickaël Salaün (May 17)
- Re: Linux: Disabling network namespaces Solar Designer (Apr 15)
- Re: Linux: Disabling network namespaces Solar Designer (Apr 19)
- Re: Linux: Disabling network namespaces Simon McVittie (Apr 19)
- Re: Linux: Disabling network namespaces Solar Designer (Apr 20)
- Re: Linux: Disabling network namespaces Jordan Glover (Apr 20)
- Re: Linux: Disabling network namespaces Simon McVittie (Apr 21)
- Re: Linux: Disabling network namespaces Priedhorsky, Reid (Apr 22)
- Re: Linux: Disabling network namespaces Solar Designer (Apr 21)
- Re: Linux: Disabling network namespaces Jordan Glover (Apr 22)
- Re: Linux: Disabling network namespaces Demi Marie Obenour (Apr 23)
- Re: Linux: Disabling network namespaces Simon McVittie (Apr 23)
- Re: Re: Linux: Disabling network namespaces John Johansen (Apr 29)