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 EDD6B2070F; Fri, 19 Sep 2025 13:18:08 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id F3487205F6; Fri, 19 Sep 2025 13:18:06 +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-b1-smtp.messagingengine.com (fout-b1-smtp.messagingengine.com [202.12.124.144]) by atuin.qyliss.net (Postfix) with ESMTPS id 4DAE3205F4 for ; Fri, 19 Sep 2025 13:18:03 +0000 (UTC) Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfout.stl.internal (Postfix) with ESMTP id 12D8B1D000EC; Fri, 19 Sep 2025 09:18:01 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Fri, 19 Sep 2025 09:18:01 -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=1758287880; x=1758374280; bh=Xyg8Tl7ma6 wfMyQ2j5/sS8YHWVHAPKi1PybfIYjtr9U=; b=cidhsi6KHrmJiT3OUA1jV7ae2p +QKpQZVuoCC19FYFQxnxfestii9m7cqJJ93OXw/bDx2jm1IxlT00np12AnEgxq7q B/+hjcDvX74cpsbMzanRLASpfmXB08/ajPLZisYrnOHgk+TmRPnQwC3D4lZqXqGp 9/xzR2JfDMmK2e/AbqUJu412xUR3kwZkqxOBqnsyWaO/MWDnxZ0sVr1VvfgTAuFS S5NXBFaGJYQ+UBjbc/ZbwwvgIf0BtjUuoX2VBp/O/Yt81TkKtGxo6V3I9RgSC58M o451tpMT+J4Wt4y2EUAgY0ijnyrJbyEqHeLJ21d2Vg3v4K6h9XKOCgMJTklQ== 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= 1758287880; x=1758374280; bh=Xyg8Tl7ma6wfMyQ2j5/sS8YHWVHAPKi1Pyb fIYjtr9U=; b=g/PRvpCYob8/yp9Y0rj3MVHOFmaoIOBb2J+00xLH6qeBfVOUE4j qk8o+g5DbSY1Ek4rm1ZWGdgMgO1VALFevnDk0jFqwp5mbOjEyhgeISnQxXOMpTAj BchFEYN8IUI0v10Yl+qEYTBk/grBOfC0YDrJv3jPEVXUx/ci9G1Ir63toeLFEnZs j9bmc3m22p+lJX+qfddMlQ1mPJyQLgvbOUED5a2EKti3C6vPhlVUPbwejqEFWNn0 YmDxyIUa38hu3d0ggpoRR2GZiSOnrquKDxR+CpuxPwcISCd107WrrqJzZwvJYRU7 JU3o/d02tQr53hdSTX5NeVB1eLmh5fc09DA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdegleefudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufgjfhffkfggtgesghdtreertddtjeenucfhrhhomheptehlhihsshgrucft ohhsshcuoehhihesrghlhihsshgrrdhisheqnecuggftrfgrthhtvghrnhepgfeffeejvd euueetteekhfffgeejjeetfeehkeeuudduffeggffffedvgeelfeeknecuffhomhgrihhn pehgihhtlhgrsgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehhihesrghlhihsshgrrdhishdpnhgspghrtghpthhtohepvddpmhho uggvpehsmhhtphhouhhtpdhrtghpthhtohepuggvmhhiohgsvghnohhurhesghhmrghilh drtghomhdprhgtphhtthhopeguvghvvghlsehsphgvtghtrhhumhdqohhsrdhorhhg X-ME-Proxy: Feedback-ID: i12284293:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 19 Sep 2025 09:18:00 -0400 (EDT) Received: by mbp.qyliss.net (Postfix, from userid 1000) id 311E11FB9132; Fri, 19 Sep 2025 15:17:39 +0200 (CEST) From: Alyssa Ross To: Demi Marie Obenour Subject: Re: Sandboxing strategy In-Reply-To: <88e28fdf-2d77-429f-8b4f-8cef4a997ed7@gmail.com> References: <87o6ritk9q.fsf@alyssa.is> <37d4dc51-4ee1-4ccf-8d37-2272988b9361@gmail.com> <871po5z5df.fsf@alyssa.is> <88e28fdf-2d77-429f-8b4f-8cef4a997ed7@gmail.com> Date: Fri, 19 Sep 2025 15:17:38 +0200 Message-ID: <87qzw2shsd.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Message-ID-Hash: LTWYPVBQMQQDRLWXBZTKCASVD65N4LDL X-Message-ID-Hash: LTWYPVBQMQQDRLWXBZTKCASVD65N4LDL 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/17/25 07:27, Alyssa Ross wrote: >> Demi Marie Obenour writes: >>=20 >>> On 9/10/25 11:11, Alyssa Ross wrote: >>>> =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. >>> >>> 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. >>=20 >> Do we not trust virtiofsd's built-in sandboxing? > > I do trust it, provided that it is verifiable (by dumping the state > of the process at runtime). However, allowing unrestricted > open_by_handle_at() allows opening any file on the system, conditioned > only on the filesystem supporting open_by_handle_at(). Therefore, > sandboxing and using handles for all filesystem access are incompatible. Wouldn't it be limited to only files on the same filesystem, since you have to pass a mount FD to open_by_handle_at()? That's still bad though. So then to start with we just want to make sure it doesn't have CAP_DAC_READ_SEARCH, and then we hope that something comes along to address the limitations of that? --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRV/neXydHjZma5XLJbRZGEIw/wogUCaM1X8gAKCRBbRZGEIw/w otHZAPwOpJZqBCTxWtDFtQfEPHF9EMW7ff3hwEOfvZD9AqENqQD/V0uiU3kktpzl 7ljYjOxAmq8YQxeZP9dOOz60/iho1Qc= =C841 -----END PGP SIGNATURE----- --=-=-=--