From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 7073C8D12; Wed, 10 Sep 2025 15:11:50 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id 946F48C5A; Wed, 10 Sep 2025 15:11:47 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DMARC_MISSING,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=unavailable autolearn_force=no version=4.0.1 Received: from fout-a1-smtp.messagingengine.com (fout-a1-smtp.messagingengine.com [103.168.172.144]) by atuin.qyliss.net (Postfix) with ESMTPS id BAA668C57 for ; Wed, 10 Sep 2025 15:11:45 +0000 (UTC) Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfout.phl.internal (Postfix) with ESMTP id 1E787EC0440; Wed, 10 Sep 2025 11:11:43 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Wed, 10 Sep 2025 11:11:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1757517103; x=1757603503; bh=6tkCPNy9Xg 84hplFVk62syDDz8+FtVrPQkLppCKLwns=; b=gjhqJAeYQHe2qbhkjeVF5xiOy5 LT6Nva6NqMlLcZQ42RQcxVRbk1dDbJer4bpzyAsYZzUrzfZgq464CN6aWtFOb5mo UczDvqLUOSnMeKC3uxBE6/su6ezrKPQga0VYvMRxlSqA+fXD5ZyJ1Q/Q/DGUmdVk EBZVHp6eDIwcCp5w/2hf/9evlWNpXvCrfXQvPfGaM5jsUP9NiC7h5ZS4mnF1naJ9 UvNVE4Zmi2kIEiiVbjFKI9RwAxEnhc2vAbFd8mtuM8TReqQECYfpsYn8+UHbjAH4 1q+NYVt0kZo1x1bjEiem1lfCBRA61LyEGP3DpbIHhm3I+cjyKFD88i0vt2Rw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1757517103; x=1757603503; bh=6tkCPNy9Xg84hplFVk62syDDz8+FtVrPQkL ppCKLwns=; b=eHaNpRBScAo0ZuFktOKQAFaqXu3ikq66tH5F3D+2FTiyXe3Z8fw 3zBNUzHAFNvOcIyJAyvJqMXi9GOQdsOfdZO04CB6PmOE6ARDP//bJGgdiNSynw5W 1eMhAX+M1Z86DlpneiVZwyg7Ja+0bXCm1KjCryOqPs0VSHfWA91yLgOe7Pi2jVax ZUiIGgXgvjTV2pLyiDa7pIIWcEQOsH7L+W9amPxvZeCr0Cl5a4ZlQyv9H0mk0SH8 rZIleoLG3d49oQsKYE+3cPHHPpW3SGIDsTaOvrGng3eqrudYzR++AAfafUIxhX2I jKd/31764vwe1Xa1rDVnwOK5y7EYMC3uDJw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvfeeiudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufgjfhffkfggtgesghdtreertddtjeenucfhrhhomheptehlhihsshgrucft ohhsshcuoehhihesrghlhihsshgrrdhisheqnecuggftrfgrthhtvghrnhepteehvedugf ejgfehhfeijeduleekleejgedvkeeuuefhhfegvdevfeetveegteeinecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhephhhisegrlhihshhsrgdrih hspdhnsggprhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegu vghmihhosggvnhhouhhrsehgmhgrihhlrdgtohhmpdhrtghpthhtohepuggvvhgvlhessh hpvggtthhruhhmqdhoshdrohhrgh X-ME-Proxy: Feedback-ID: i12284293:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 10 Sep 2025 11:11:42 -0400 (EDT) Received: by mbp.qyliss.net (Postfix, from userid 1000) id 058E616EF615; Wed, 10 Sep 2025 17:11:30 +0200 (CEST) From: Alyssa Ross To: Demi Marie Obenour Subject: Re: Sandboxing strategy In-Reply-To: References: Date: Wed, 10 Sep 2025 17:11:29 +0200 Message-ID: <87o6ritk9q.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Message-ID-Hash: EQ5GXTSRY2I6JNOATRGJTM7LUTM4RHMQ X-Message-ID-Hash: EQ5GXTSRY2I6JNOATRGJTM7LUTM4RHMQ X-MailFrom: hi@alyssa.is X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-devel.spectrum-os.org-0; header-match-devel.spectrum-os.org-1; header-match-devel.spectrum-os.org-2; header-match-devel.spectrum-os.org-3; header-match-devel.spectrum-os.org-4; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Spectrum OS Development X-Mailman-Version: 3.3.9 Precedence: list List-Id: Patches and low-level development discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Demi Marie Obenour writes: > I was thinking about how to sandbox the various per-VM daemons > and came up with the following strategy: > > - Each VM gets its own PID and mount namespace and set of user IDs. Didn't you say to me we couldn't do PID namespaces without support from s6? > - Mount namespace includes /proc, /sys, /dev, and the host rootfs. > > - Each service gets its own /tmp and /dev/shm if they are needed at all. Just a question: if we put services into cgroups, does use of tmpfs get charged to the appropriate cgroup? > - virtiofsd gets r/w access to the VM private storage. > > - IPC namespaces are irrelevant because the kernel is > built without System V IPC or POSIX message queues. > > - Sending signals between services in the namespace is blocked > by Landlock. Landlock also blocks ptrace() and other nastiness, > as well as communication via abstract AF_UNIX sockets. > > - Since AF_UNIX abstract sockets between services are blocked by > Landlock and Spectrum builds without IP or even Ethernet on the > host there is no need for network namespacing. It doesn't currently, just to be clear. (I'm still putting off using a custom kernel config on the host until we have better tooling for keeping up with Nixpkgs.) > - The sandbox manager is PID 1 in the VM's PID namespace. > When s6 tells it to shut down, it tries to gracefully shut > down the VM. After a timeout or once the VM has shut down, > it exits, and Linux automatically kills all the processes > and cleans up the mount namespace. > > - The sandbox manager uses prctl(PR_SET_PDEATHSIG) to ensure it > dies if the parent s6 process dies. This requires s6 to provide > its own PID to avoid races, but that is easy to implement. > > All of this behavior will be hard-coded into C and Rust source code, > so it will be vastly simpler than a generic program that must support > many use-cases. This all sounds fine, BUT there are a couple of important things to bear in mind: =E2=80=A2 This needs to be maintainable. I don't know how much code this = is going to be our how complex it's going to be, but that this will be totally custom does make me a bit concerned. =E2=80=A2 These services are part of our TCB anyway. Sandboxing only gets= us defense in depth. With that in mind, it's basically never going to be worth adding sandboxing if it adds any amount of attack surface. One example of that would be user namespaces. They've been a consistent source of kernel security issues, and it might be better to turn them off entirely than to use them for sandboxing stuff that's trusted anyway. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRV/neXydHjZma5XLJbRZGEIw/wogUCaMGVIQAKCRBbRZGEIw/w omoiAQCUxQhRb5ZESWiKgJbRDVT9+8rt3m28lYRDkX+HzviXQQEAgxQg1Fleyeh6 cvQwRFlaEMoYhp7pSiDcsDnvkgB4JQA= =UDrs -----END PGP SIGNATURE----- --=-=-=--