Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sun, 14 Apr 2024 21:08:55 +0200
From: Solar Designer <>
Subject: Linux: Disabling network namespaces


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:

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

 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" \
   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
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

.. code:: bash

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

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


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.