[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <354b913bc1c154c1e3a2fc34ed8ed6b0d4641f11.camel@canonical.com>
Date: Wed, 17 Apr 2024 09:52:10 -0300
From: Georgia Garcia <georgia.garcia@...onical.com>
To: oss-security@...ts.openwall.com
Subject: Re: Linux: Disabling network namespaces
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
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.
