oss-sec mailing list archives
Re: Linux: Disabling network namespaces
From: Solar Designer <solar () openwall com>
Date: Mon, 15 Apr 2024 17:13:09 +0200
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
Current thread:
- Linux: Disabling network namespaces Solar Designer (Apr 14)
- Re: Linux: Disabling network namespaces Demi Marie Obenour (Apr 15)
- 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 Demi Marie Obenour (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)