Received-SPF: pass (google.com: domain of oss-security-return-30025-linux.lists.archive=gmail.com@lists.openwall.com designates 193.110.157.125 as permitted sender) client-ip=193.110.157.125;
Mailing-List: contact oss-security-help@lists.openwall.com; run by ezmlm
Precedence: bulk
Reply-To: oss-security@lists.openwall.com
Date: Sun, 14 Apr 2024 21:08:55 +0200
From: Solar Designer <solar@openwall.com>
To: oss-security@lists.openwall.com
Message-ID: <20240414190855.GA12716@openwall.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Subject: [oss-security] Linux: Disabling network namespaces

Hi,

Many Linux kernel vulnerabilities including the recently exploited
Netfilter CVE-2024-1086 require CAP_NET_ADMIN in a namespace, yet a
typically recommended mitigation is to disable user namespaces (not just
network namespaces).

Further, while on Debian/Ubuntu it is possible to disable just
unprivileged user namespaces with the Debian-specific sysctl
kernel.unprivileged_userns_clone=0, on other distros we'd have to use
user.max_user_namespaces=0, which (unnecessarily) prevents starting of
containers even by root.

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.

I include this section of the Apptainer documentation below, as taken
from its source at
https://github.com/apptainer/apptainer-admindocs/blob/main/user_namespace.rst

---
******************************
 Disabling network namespaces
******************************

There have been many Linux kernel exploits that have made use of
unprivileged user namespaces as a point of entry, but almost all of them
in the last few years have been in combination with network namespaces.
Therefore even though the Apptainer project recommends enabling
unprivileged user namespaces, it recommends disabling network namespaces
when possible in order to substantially reduce the risk profile
and need for urgent updates when vulnerabilities are announced.

Network namespaces can be disabled on most Linux-based systems
like this:

.. code:: bash

   echo "user.max_net_namespaces = 0" \
        >/etc/sysctl.d/90-max_net_namespaces.conf
   sysctl -p /etc/sysctl.d/90-max_net_namespaces.conf

Apptainer does not by default make use of network namespaces, but it
does have some little-used privileged options beginning with ``--net``
that do.
Those options will not work when network namespaces are disabled.
Unfortunately it is not possible to disable only unprivileged
network namespaces, so this will affect programs that use them
even if run as root.

Some other container runtimes such as Docker and Podman do make use
of network namespaces by default.
Those two runtimes can still work when network namespaces are disabled
by adding the ``--net=host`` option.

Disabling network namespaces also blocks the systemd PrivateNetwork
feature.
To find services that use it, look for ``PrivateNetwork=true``
or ``PrivateNetwork=yes`` in ``/lib/systemd/system/*.service``.
This can be turned off for each service through a
``/etc/systemd/system/<service>.d/*.conf`` file, for example for
``systemd-hostnamed``:

.. code:: bash

   cd /etc/systemd/system
   mkdir -p systemd-hostnamed.service.d
   (echo "[Service]"; echo "PrivateNetwork=no") \
        >systemd-hostnamed.service.d/no-private-network.conf

If the service is enabled (that is, actively used) then restart it
and check its status:

.. code:: bash

   systemctl status systemd-hostnamed
   systemctl daemon-reload
   systemctl restart systemd-hostnamed
   systemctl status systemd-hostnamed
---

Alexander