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 88C3B1365E; Wed, 17 Sep 2025 11:27:31 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id C2D5213641; Wed, 17 Sep 2025 11:27:28 +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 fhigh-a6-smtp.messagingengine.com (fhigh-a6-smtp.messagingengine.com [103.168.172.157]) by atuin.qyliss.net (Postfix) with ESMTPS id 3409F1363F for ; Wed, 17 Sep 2025 11:27:27 +0000 (UTC) Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfhigh.phl.internal (Postfix) with ESMTP id 5AD2114001F2; Wed, 17 Sep 2025 07:27:26 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Wed, 17 Sep 2025 07:27:26 -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=1758108446; x=1758194846; bh=P3YwqIqhUC JZUUmyXtmwVp1Weu/QYerftFrwyEzt/bE=; b=JOZuXR+E9/yKa+yFHmqdMckEIU U6LjniouLB5Oq86+bvWwecANS2izRFKbDwFmuS+krW74XbC1cp4+J36tdQHkb126 o2lbSBseyqw613WE/F2MJbWvhOLRKUbeNq+IiH+/ddUoNnk+m2nmiOqwwVKmq3zN 58i/24Tih4rML1ceBzJZ1cB7Pio01t6AdR8txHqGNIGdM1kiKT8ckz0O9AIHievv MYekz631i1sxPG00aKWKsdxnG1WBUOm7M7udp8ux5p+/IL0Hnr0AksyLj0ASDtk4 jocxJZGobc0TIrh7NntoH+gGiW8knJcOPen4FhVSP4z03WJrYe5f9wruCM8A== 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= 1758108446; x=1758194846; bh=P3YwqIqhUCJZUUmyXtmwVp1Weu/QYerftFr wyEzt/bE=; b=NvWnnxo8osA2UhtoE2BIeXfn9OHPgBCTZfBxTtg6WQExJe5wJrg cR0txM9u+8LryR3KN3yeb0l+hY8/9fP76Nt88Em9u6pYjsV7St3ZSBVTlY+o/roh pNnH5rHdEePbsV5K2ZkXP4VN5dUj1YZoenzRYaAUSsbU96VK+XuoRsR/IWg+a9qt 9x3MA5G3mdva23B/eFNJ++TNmKInXRCBafs6DJfmOtlfeiqVINmx8jcYGDHU1UJ2 80aQGtcWkny98CTSq30Kf9KJHrgE6NfeRU2klvKD2g6taaY+LEKtL2JHh3mM882G nL+8gn4uJqYx0OeEJCh2AnsxDYcH21m4nLg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdegfeeffecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufgjfhffkfggtgesghdtreertddtjeenucfhrhhomheptehlhihsshgrucft ohhsshcuoehhihesrghlhihsshgrrdhisheqnecuggftrfgrthhtvghrnhepgfeffeejvd euueetteekhfffgeejjeetfeehkeeuudduffeggffffedvgeelfeeknecuffhomhgrihhn pehgihhtlhgrsgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehhihesrghlhihsshgrrdhishdpnhgspghrtghpthhtohepvddpmhho uggvpehsmhhtphhouhhtpdhrtghpthhtohepuggvmhhiohgsvghnohhurhesghhmrghilh drtghomhdprhgtphhtthhopeguvghvvghlsehsphgvtghtrhhumhdqohhsrdhorhhg X-ME-Proxy: Feedback-ID: i12284293:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 17 Sep 2025 07:27:25 -0400 (EDT) Received: by mbp.qyliss.net (Postfix, from userid 1000) id F3D4A1F50D94; Wed, 17 Sep 2025 13:27:09 +0200 (CEST) From: Alyssa Ross To: Demi Marie Obenour Subject: Re: Sandboxing strategy In-Reply-To: <37d4dc51-4ee1-4ccf-8d37-2272988b9361@gmail.com> References: <87o6ritk9q.fsf@alyssa.is> <37d4dc51-4ee1-4ccf-8d37-2272988b9361@gmail.com> Date: Wed, 17 Sep 2025 13:27:08 +0200 Message-ID: <871po5z5df.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Message-ID-Hash: C25NR24LDGO6QTDVK67JCVXEWF2IE7YM X-Message-ID-Hash: C25NR24LDGO6QTDVK67JCVXEWF2IE7YM 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: > On 9/10/25 11:11, Alyssa Ross wrote: >> This all sounds fine, BUT there are a couple of important things to bear >> in mind: >>=20 >> =E2=80=A2 This needs to be maintainable. I don't know how much code th= is 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. > > This should not be too difficult. It's the same system calls used by > container managers, so if there is a problem it should be possible to > get help fairly easily. bubblewrap=20 bubblewrap? :) >> =E2=80=A2 These services are part of our TCB anyway. Sandboxing only g= ets 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. > > Sandboxing virtiofsd is going to be really annoying and will definitely > come at a performance cost. The most efficient way to use virtiofsd > is to give it CAP_DAC_READ_SEARCH in the initial user namespace and > delegate _all_ access control to it. This allows virtiofs to use > open_by_handle_at() for all filesystem access. Unfortunately, > this also allows virtiofsd to open any file on the filesystem, ignoring > all discretionary access control checks. I don't think Landlock would > work either. SELinux or SMACK might work, but using them is > significantly more complicated. > > If one wants to sandbox virtiofsd, one either needs to > use --cache=3Dnever or run into an effective resource leak > (https://gitlab.com/virtio-fs/virtiofsd/-/issues/194). > My hope is that in the future the problem will be solved > by DAX and an in-kernel shrinker that is aware of the host > resources it is using. Denial of service would be prevented > by cgroups on the host, addressing the objection mentioned > in the issue comments. Do we not trust virtiofsd's built-in sandboxing? --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRV/neXydHjZma5XLJbRZGEIw/wogUCaMqbDAAKCRBbRZGEIw/w ojINAQCiBb8lVfBnU56Ktlj3FhDRyATOMuiQYVpQn9E7Nh3WkwEAtQryYLG1mtKj tVSF+r2bMJh1umtAeiy7iy84iYTdXAk= =dA/m -----END PGP SIGNATURE----- --=-=-=--