[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 15 Apr 2024 16:47:18 +0100
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: Linux: Disabling network namespaces
On Mon, 15 Apr 2024 at 17:13:09 +0200, Solar Designer wrote:
> And/or make Debian's
> kernel.unprivileged_userns_clone official upstream and use that. Why
> did Debian choose to deprecate (but not yet drop?) theirs and go with
> upstream's user.max_user_namespaces, which doesn't provide exactly the
> same functionality? Was there an attempt at upstreaming?
I am not a kernel developer, so this is second-hand information; but I
believe the implementation of kernel.unprivileged_userns_clone used in
Debian (and subsequently copied from Debian by various other distros)
is derived from patches that were already proposed and rejected upstream,
so the feeling was that trying again to upstream that feature would be a
waste of time and upstream goodwill, because it would just get rejected
again by the same kernel maintainer.
kernel.unprivileged_userns_clone was a tradeoff between kernel attack
surface and user-space attack surface. Disabling it mitigates various
attacks that user-space can attempt on the kernel, but forces user-space
sandboxing things (such as bubblewrap and the Chromium sandbox) to
be setuid root if they are going to be used, which turns them into a
user-space root privilege escalation risk. Conversely, with unprivileged
namespaces, we can sandbox user-space processes without adding that risk,
but we're relying on a larger kernel attack surface being secure.
(Current versions of Debian still have the kernel.unprivileged_userns_clone
patch, but it's left enabled by default, resulting in behaviour that is
equivalent to upstream kernels.)
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.
