Received-SPF: pass (google.com: domain of oss-security-return-30057-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
Date: Fri, 19 Apr 2024 18:25:02 +0100
From: Simon McVittie <smcv@debian.org>
To: oss-security@lists.openwall.com
Message-ID: <ZiKo7shztRpgvAIC@remnant.pseudorandom.co.uk>
References: <20240414190855.GA12716@openwall.com>
 <354b913bc1c154c1e3a2fc34ed8ed6b0d4641f11.camel@canonical.com>
 <20240419154435.GA7046@openwall.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240419154435.GA7046@openwall.com>
Subject: Re: [oss-security] Linux: Disabling network namespaces

On Fri, 19 Apr 2024 at 17:44:35 +0200, Solar Designer wrote:
> I guess
> systemd's PrivateNetwork services generally don't configure networking
> (they just give up network access), so would continue to work even with
> capabilities disallowed?

I can't speak for systemd's PrivateNetwork services, but for the
bubblewrap use-cases that I described elsewhere in the thread (Flatpak,
libgnome-desktop etc.), `bwrap --unshare-net` does bring up the "lo"
interface with address 127.0.0.1 and a route to 127.0.0.0/8 before it
relinquishes its capabilities and execs the sandboxed program.

Presumably this is because it's common for ordinary user-space applications
to assume that they can "talk to themselves" via loopback, even if there is
no external connectivity.

    smcv