[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240414190855.GA12716@openwall.com>
Date: Sun, 14 Apr 2024 21:08:55 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: 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
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.
