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 A031EEE78; Sun, 14 Dec 2025 10:53:01 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id EA26AEE95; Sun, 14 Dec 2025 10:52:57 +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-a7-smtp.messagingengine.com (fout-a7-smtp.messagingengine.com [103.168.172.150]) by atuin.qyliss.net (Postfix) with ESMTPS id 2F684EE66 for ; Sun, 14 Dec 2025 10:52:57 +0000 (UTC) Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfout.phl.internal (Postfix) with ESMTP id E625EEC0608; Sun, 14 Dec 2025 05:52:54 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-01.internal (MEProxy); Sun, 14 Dec 2025 05:52:54 -0500 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=1765709574; x=1765795974; bh=La047ueTbV 7kCTRhO7rjfN4o1OxFALxjRwOGCrvkIFI=; b=adewp9QwPPLB+HoJ4TAR5cdC5B D4ZM2shM+Ff2PJSyVY4jA8yNdfNwixK308eTDbBWPLCaGlFQnNynw4iEvGJE0LQJ qHUPGl2UO1wVgYDytmDfIryl7PYW/v6QjncLox5juJ2eQ0Cx77WzCOnPmG92X7Vv REEmAx+QrC0uutN9+CNRGtne0nA20DM0chpHiRQKssqmMo9Ud4+rz85lIUTEnGo4 CUOMIvAMYKbdHyj9oYOH5CkG7fPRlrpriAmSRzeWE4HkIpBhJe1bi0jtw52ouF1w xYpx4glCkgRK0EPaWtryrlbyhFrLW/drFXpRpN7p4cdJsQlRWJRUn/oV1AmA== 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= 1765709574; x=1765795974; bh=La047ueTbV7kCTRhO7rjfN4o1OxFALxjRwO GCrvkIFI=; b=xUbS91nq98dM9DI+Q5rdRpAPCFQONI2zbkHlYjtHEBW0DZ22mW0 Xgfn7hbpGMPffjsN/erUVQc84HGevDDesC8fPI+SBQr94tYPx6XHUeiuAUDIZz60 wg2XxAQV6bxMLrnAOLtpnev+XXwxl1BarK9dRNdnNDkt/Ph3lyQO8A6bCyEl3nsv ALOTyrlbOUeY0IHLtaMTiYDHw4chixL2SlLH0VncJ3sT/j6MonH4a0KQWNYtlwF1 DGg3iAqd0eWJoUdQgaqWYnMo5WWVk8ttX37xrvg7cwNS/yxlBTEit6yiUwuoISZc 8QrmigCeS7rOY1hb8oxsA9w3TBfcCFtCzAQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdeffeejfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufgjfhffkfggtgesghdtreertddtjeenucfhrhhomheptehlhihsshgrucft ohhsshcuoehhihesrghlhihsshgrrdhisheqnecuggftrfgrthhtvghrnhepteehvedugf ejgfehhfeijeduleekleejgedvkeeuuefhhfegvdevfeetveegteeinecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhephhhisegrlhihshhsrgdrih hspdhnsggprhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegu vghmihhosggvnhhouhhrsehgmhgrihhlrdgtohhmpdhrtghpthhtohepuggvvhgvlhessh hpvggtthhruhhmqdhoshdrohhrgh X-ME-Proxy: Feedback-ID: i12284293:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 14 Dec 2025 05:52:54 -0500 (EST) Received: by fw12.qyliss.net (Postfix, from userid 1000) id 5C08F7BF8C0D; Sun, 14 Dec 2025 11:52:43 +0100 (CET) From: Alyssa Ross To: Demi Marie Obenour Subject: Re: [PATCH] host/roots: Sandbox xdg-desktop-portal-spectrum-host In-Reply-To: <515ff0f4-2ab3-46de-8d1e-5c66a93c6ede@gmail.com> References: <20251212-sandbox-dbus-portal-v1-1-522705202482@gmail.com> <87o6o25h6y.fsf@alyssa.is> <87ikea5a8x.fsf@alyssa.is> <00256266-26db-40cf-8f5b-f7c7064084c2@gmail.com> <87bjk16dvv.fsf@alyssa.is> <515ff0f4-2ab3-46de-8d1e-5c66a93c6ede@gmail.com> Date: Sun, 14 Dec 2025 11:52:41 +0100 Message-ID: <877bup2v46.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Message-ID-Hash: DYMJIEYBL3ISOGN6GAZ5EARBOOL4E74C X-Message-ID-Hash: DYMJIEYBL3ISOGN6GAZ5EARBOOL4E74C 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 12/13/25 20:39, Alyssa Ross wrote: >> Demi Marie Obenour writes: >>=20 >>> On 12/13/25 16:42, Alyssa Ross wrote: >>>> Demi Marie Obenour writes: >>>> >>>>> On 12/13/25 14:12, Alyssa Ross wrote: >>>>>> Demi Marie Obenour writes: >>>>>> >>>>>>> It is quite possible that these Landlock rules are unnecessarily >>>>>>> permissive, but all of the paths to which read and execute access is >>>>>>> granted are part of the root filesystem and therefore assumed to be >>>>>>> public knowledge. Removing access from any of them would only incr= ease >>>>>>> the risk of accidental breakage in the future, and would not provid= e any >>>>>>> security improvements. seccomp *could* provide some improvements, = but >>>>>>> the effort needed is too high for now. >>>>>>> >>>>>>> Signed-off-by: Demi Marie Obenour >>>>>>> --- >>>>>>> .../template/data/service/xdg-desktop-portal-spectrum-host/run = | 8 ++++++++ >>>>>>> 1 file changed, 8 insertions(+) >>>>>> >>>>>> Are you sure this is working as intended? There's no rule allowing >>>>>> access to Cloud Hypervisor's VSOCK socket, and yet it still seems to= be >>>>>> able to access that. Don't you need to set a rule that *restricts* >>>>>> filesystem access and then add holes? Did you ever see this deny >>>>>> anything? >>>>> >>>>> 'man 1 setpriv' states that '--landlock-access fs' blocks all >>>>> filesystem access unless a subsequent --landlock-rule permits it. >>>>> I tried running with no --landlock-rule flags and the execve of >>>>> xdg-desktop-portal-spectrum-host failed as expected. >>>>> >>>>> The socket is passed over stdin, and I'm pretty sure Landlock >>>>> doesn't restrict using an already-open file descriptor. >>>>> xdg-desktop-portal-spectrum-host does need to find the path to the >>>>> socket, but I don't think it ever accesses that path. >>>> >>>> I've been looking into this a bit myself, and from what I can tell >>>> Landlock just doesn't restrict connecting to sockets at all, even if >>>> they're inside directories that would otherwise be inaccessible. It's >>>> able to connect to both Cloud Hypervisor's VSOCK socket and the D-Bus >>>> socket even with a maximally restrictive landlock rule. So you were >>>> right after all, sorry! >>> >>> That's not good at all! It's a trivial sandbox escape in so many cases. >>> For instance, with access to D-Bus I can just call `systemd-run`. >>> >>> I'm CCing the Landlock and LSM mailing lists because if you are >>> correct, then this is a bad security hole. >>=20 >> I don't find it that surprising given the way landlock works. "connect" >> (to a non-abstract AF_UNIX socket) is not an operation there's a >> landlock action for, and it's not like the other actions care about >> access to parent directories and the like =E2=80=94 I was able to execut= e a >> program via a symlink after only giving access to the symlink's target, >> without any access to the directory containing the symlink or the >> symlink itself, for example. Landlock, as I understand it, is intended >> to block a specified set of operations (on particular file hierarchies), >> rather than to completely prevent access to those hierarchies like >> permissions or mount namespaces could, so the lack of a way to block >> connecting to a socket is more of a missing feature than a security >> hole. > > 'man 7 unix' states: > > On Linux, connecting to a stream socket object requires write > permission on that socket; sending a datagram to a datagram socket > likewise requires write permission on that socket. > > Landlock is definitely being inconsistent with DAC here. Also, this > allows real-world sandbox breakouts. On systemd systems, the simplest > way to escape is to use systemd-run to execute arbitrary commands. (UnCCing the landlock and LSM lists because I don't think they're going to get much from this.) Yes, Landlock is inconsistent with DAC. They are two different mechanisms. "Write permission" is not a Landlock concept ("write file" is, but it's specifically for files), and I don't think Landlock is intended to be a complete sandbox all on its own. It is a mechanism to restrict specific, enumerated operations, and it is working here as described. Nowhere is it promised that turning on the whole set of restrictions gets you a complete sandbox. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQGoGac7QfI+H5ZtFCZddwkt31pFQUCaT6W+QAKCRCZddwkt31p FVWIAP98oJNRCrYv1bYT9eKoopiU1ykwjdGw/PDy/rlJcUTe4gEAvwfIQZYsReqv Zk3hwlT0UL+xZN2x5qfEnF3+8jWX8AA= =lI+Q -----END PGP SIGNATURE----- --=-=-=--