Received-SPF: pass (google.com: domain of oss-security-return-30027-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
Feedback-ID: iac594737:Fastmail
Date: Sun, 14 Apr 2024 18:47:26 -0400
From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: oss-security@lists.openwall.com
Message-ID: <ZhxdDyIBazJYRDeR@itl-email>
References: <20240414190855.GA12716@openwall.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="OjNm5EQIZcjK10WQ"
Content-Disposition: inline
In-Reply-To: <20240414190855.GA12716@openwall.com>
Subject: Re: [oss-security] Linux: Disabling network namespaces

--OjNm5EQIZcjK10WQ
Content-Type: text/plain; protected-headers=v1; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Sun, 14 Apr 2024 18:47:26 -0400
From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: oss-security@lists.openwall.com
Subject: Re: [oss-security] Linux: Disabling network namespaces

On Sun, Apr 14, 2024 at 09:08:55PM +0200, Solar Designer wrote:
> Hi,
>=20
> 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).
>=20
> Further, while on Debian/Ubuntu it is possible to disable just
> unprivileged user namespaces with the Debian-specific sysctl
> kernel.unprivileged_userns_clone=3D0, on other distros we'd have to use
> user.max_user_namespaces=3D0, which (unnecessarily) prevents starting of
> containers even by root.
>=20
> Fredrik Nystrom on Rocky Linux Mattermost channel Security pointed out
> that it is reasonable to disable just network namespaces with
> user.max_net_namespaces=3D0 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:
>=20
> https://apptainer.org/docs/admin/latest/user_namespace.html#disabling-net=
work-namespaces
>=20
> I hope some of us in here find this useful, and maybe we (including
> distros) will start recommending this milder mitigation when sufficient.

Is this still compatible with Firefox?

IMO an ideal solution would be:

1. Provide a privileged helper daemon that sets up containers based on
   user requirements.

2. Port programs that use containers to use this helper.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

--OjNm5EQIZcjK10WQ
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmYcXQ0ACgkQsoi1X/+c
IsE6ow/6AxYK95tcs1UytdbKhP4OGFCwg7WeZka4rNEpcHuhER/gVtcPmX4zt5NS
VJUeHURwF+MXB7SfAdDMt9qtHzUHOiyKwVyv4dkD0qO4SM99NVi7jT0FFchE5YD9
4Ky554KtyDxId1v0EzyZTDSGBjfXLmc0O9A6FFqDnm98ruqtCjmq7gRSkk9rfP05
LTyZkBuYwwV9Ad+w/xpElcNKrw2tZNEtZBqXvfIppZoAoPJceqsAEYULbVF5SEcr
DQRutUjCAh20NWat9B4o3zxe3gXu8KTJF7leV7HPJxVGwK9j7x6Rh49Ft41syJj6
Ae+UjiUYtly6hEOpsbBGptTCGhczGy9qw/EQACWiu/D3QN9uKX/ChGvpCaOY+1X6
d86XgkDBJ2mmW3xYBheHrLKDwVKiheTXJ9K7bfW+M3Ftr4Wn45sy4SF7XUi1SZe8
FHDSp0nkAblIUTimEBx59E3h3yysGspT40xJ8waTYCTVytpnrBF/FcX8mY21LEru
dfGmFlb2O4D22jgn+hN3VkSC08iBinB+pAp6OruUrRBk7ho24ihjo4O2YUam+diD
WuZn0cqNcpaWMqpI8daXvh4F6uE8IyXtcshGJpqr56813j8If+7UEEvAbGvlky/i
uec06GT85Tyc+WJv3zWKPSl8SUbDDGi7tYvcXLa6E+xppb0/bww=
=Cdse
-----END PGP SIGNATURE-----

--OjNm5EQIZcjK10WQ--