[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 15 Apr 2024 17:13:09 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: Linux: Disabling network namespaces
On Sun, Apr 14, 2024 at 06:47:26PM -0400, Demi Marie Obenour wrote:
> On Sun, Apr 14, 2024 at 09:08:55PM +0200, Solar Designer wrote:
> > Fredrik Nystrom on Rocky Linux Mattermost channel Security pointed out
> > that it is reasonable to disable just network namespaces with
> > user.max_net_namespaces=0 instead, and that the negative effects of
> > doing so and how to cope with them are well-documented for Apptainer,
> > with its documentation also covering Docker, Podman, and systemd:
> >
> > https://apptainer.org/docs/admin/latest/user_namespace.html#disabling-network-namespaces
> >
> > I hope some of us in here find this useful, and maybe we (including
> > distros) will start recommending this milder mitigation when sufficient.
>
> Is this still compatible with Firefox?
No. Per my testing, setting user.max_net_namespaces=0 while keeping
user.max_user_namespaces at greater than 0 is _not_ compatible with
Firefox 124.0.2. However, setting user.max_user_namespaces=0 is
compatible with it, regardless of whether user.max_net_namespaces is 0
or not. I guess it only has fallbacks (perhaps weakening its sandbox)
for the case when user namespaces can't be created, but not for this
mixed case when user can be, but net can't.
Breaking Firefox or weakening its sandbox is indeed not great.
I primarily meant these settings for headless servers, which wouldn't
commonly run Firefox. However, even there I can see how weakening
systemd service sandboxing is also not great. Maybe we need to invent a
kernel.unprivileged_netns_clone setting similar to Debian's
kernel.unprivileged_userns_clone, so that systemd (running as root)
would still be able to create network namespaces. 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?
> IMO an ideal solution would be:
>
> 1. Provide a privileged helper daemon that sets up containers based on
> user requirements.
>
> 2. Port programs that use containers to use this helper.
Not likely to happen universally and not good in terms of introducing a
middle project and dependency that could dictate rules to others.
Alexander
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.
