oss-sec mailing list archives
Re: Linux: Disabling network namespaces
From: Georgia Garcia <georgia.garcia () canonical com>
Date: Wed, 17 Apr 2024 09:52:10 -0300
On Sun, 2024-04-14 at 21:08 +0200, Solar Designer wrote:
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.
I just wanted to add that in the Ubuntu Noble Numbat release we are using AppArmor to restrict unprivileged user namespaces. Applications that don't have an AppArmor profile will use a default profile which denies the use of capabilities within the user namespace. Applications that need to use capabilities will have to be confined by a profile. Since we understand that creating an AppArmor profile might not be a trivial task for large programs, we introduced the "unconfined" flag which makes the profile act as if it were unconfined from the perspective of AppArmor, allowing all operations. There are more details here: https://discourse.ubuntu.com/t/noble-numbat-release-notes/39890#unprivileged-user-namespace-restrictions-13
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
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)
- Re: Linux: Disabling network namespaces Priedhorsky, Reid (Apr 22)
- Re: Linux: Disabling network namespaces Solar Designer (Apr 21)
- Re: Linux: Disabling network namespaces Jordan Glover (Apr 22)
- Re: Linux: Disabling network namespaces Demi Marie Obenour (Apr 23)
- Re: Linux: Disabling network namespaces Simon McVittie (Apr 23)