From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-4.4 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,URIBL_SBL_A autolearn=unavailable autolearn_force=no version=3.4.5 Received: by atuin.qyliss.net (Postfix, from userid 496) id C916212266; Sat, 22 May 2021 15:09:17 +0000 (UTC) Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 37EB512296; Sat, 22 May 2021 15:09:00 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id 59EF612291; Sat, 22 May 2021 15:08:58 +0000 (UTC) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by atuin.qyliss.net (Postfix) with ESMTPS id 261C012234 for ; Sat, 22 May 2021 15:08:54 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 39E765C0224; Sat, 22 May 2021 11:08:53 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sat, 22 May 2021 11:08:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h= from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-type; s=fm3; bh=hTHAB0CxZVRQbSkXhq23hXcOR6 dO0LoQ425G/FDi/7Q=; b=k46ikxaV9ECNpfV1Hik0OUWsgAxlN13JR+yM8loDmO womQbDyjz/8LViBOTjHai04A2PWEIB1ZGi72r2cwe1lMry3DjBAnB2T7oSxFRCv5 OGi0KZsLoDYqyv2BXzNbQIXIAKwhWXpZ6tQ2FvC5GmZdJC5KhmAh7EkFEG+sInSq FIta6w/uxSEXGyRnMxg1W0NKsjVidvKAR3a9ItN/vbjY+kFg27QlOdEcIYmbemGR JovxQbjpj2jqOoDWbxNqT6IzhZCHSYZ9adPVjaXB1GpxWOAOqxGnrTgKMDD5Lmk1 gfhq3hQGgxwd4xJ/geCT75VIDOGBuHlLPI2IEnArj0Ww== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=hTHAB0 CxZVRQbSkXhq23hXcOR6dO0LoQ425G/FDi/7Q=; b=GjfS9Z7UXmFGixH9PTac/b a95MLimdf1Nd5O9AYeLLWfpTJ4TLPZ6Myvh9WFTBxqFXVIZwEIcHzaa1bzfakR4c MQq8XfAfBYLtD6/1IyO0bGQPVBm/M3mPCti3TQ5MNKzsotYxYIKeDTVzX93DtsJM LJhwXubruVKM2Agy2Pul379oTp/1mBYH/gZpeJxhHHVuDb2NZE2BOCtGF4GKoDd7 o5p08jP23GeHhKWBERHyGPrSYdf4mPmyBo65fsyyH8GopCp+wbD5U5LvfUuwBKS+ +XeJrFNdpMsSnFcH/enZnopbcQjOGA8yvrHEUuTd+ddcgQLou6TKIOQTM0jfK0bw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdejhedgkeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffujghffffkgggtsehgtderre dttdejnecuhfhrohhmpeetlhihshhsrgcutfhoshhsuceohhhisegrlhihshhsrgdrihhs qeenucggtffrrghtthgvrhhnpeffudduffeuffegheeigeejtdekhfduheehfeduheelff ettdekiedtgeefgfelheenucfkphepgeeirdektddrudefkedrjeefnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhephhhisegrlhihshhsrgdrih hs X-ME-Proxy: Received: from x220.qyliss.net (p2e508a49.dip0.t-ipconnect.de [46.80.138.73]) by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 22 May 2021 11:08:52 -0400 (EDT) Received: by x220.qyliss.net (Postfix, from userid 1000) id CF78FF70; Sat, 22 May 2021 15:08:50 +0000 (UTC) From: Alyssa Ross To: 7c6f434c@mail.ru, discuss@spectrum-os.org Subject: Re: Proxying Wayland for untrusted clients In-Reply-To: References: <8735ueudel.fsf@alyssa.is> <8735ueudel.fsf@alyssa.is> Date: Sat, 22 May 2021 15:08:47 +0000 Message-ID: <87h7iuztz4.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Message-ID-Hash: CEHTTCKWOCRLDPPTZCPFMKPUUOXTTMLO X-Message-ID-Hash: CEHTTCKWOCRLDPPTZCPFMKPUUOXTTMLO X-MailFrom: hi@alyssa.is X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: aaron@ajanse.me, puck@puckipedia.com, talex5@gmail.com X-Mailman-Version: 3.3.4 Precedence: list List-Id: General high-level discussion about Spectrum 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 Michael Raskin <7c6f434c@mail.ru> writes: >>One of the benefits that Wayland is supposed to have over X11 is >>security. A Wayland application isn't supposed to be able to record the >>screen without user permission, for example. But in most compositors, >>it can, with no restrictions. Existing Wayland compositors are > > =E2=80=A6 and theoretically, an X server could feed empty capture to a cl= ient it > does not like =E2=80=A6 > > (of course with literal decades of actual backwards compatibility, X11 > protocol has accumulated enough extensions that assigning permissions=20 > to all of them might be somewhat painful) Considering that the world has convered on a single X server implementation, and it's apparently pretty horrible to maintain, I'm not sure I feel very positive about the idea of a custom one! And yeah, with Wayland clients are already expecting to have to ask for permission. (I've just learned that this is actually done over DBus, so the proxy would have to implement that as well, ugh.) I suspect X11 clients wouldn't be very happy if it took them seconds to get the result of their attempted screen capture, and users wouldn't be very happy if screen sharing was just a blank box by default, rather than a permission request. (I'm not sure which of those would be possible with X11.) >>monolithic, and each one would have to implement its own access >>controls. (Mutter already does this to some extent, at least for screen >>sharing, I believe.) The popular Wayland compositors are largely >>focused on being feature-complete reimplementations of their X11 >>equivalents, and so taking advantage of the security features and access >>controls the Wayland protocol makes possible hasn't been a priority for > > =E2=80=A6 unsurprisingly, as these are typically WM teams who are now dep= rived > of what Xorg server did for everyone. Only the ones that don't use wlroots, I think. wlroots has its own problems, but in large part those are the problems we're trying to mitigate here. >>To solve these problems, I propose a proxy program that sits between >>Wayland clients and the compositor, in the same privelege domain as the >>compositor. The proxy would decode and re-encode every Wayland request >>(client->compositor message), and would discard any request it didn't >>understand. This would mitigate the problem of a large, privileged >>program written in a memory-unsafe language being exposed to untrusted > > Presumably, also validating that the shared memory buffers passed around > have the same size and protection as promised? Aren't shared memory buffers usually handed out by the compositor, to the client? IIRC this was the reason virtio wayland can work when it only supports shared memory that was allocated by the host. >>inputs. Additionally, the proxy would support a plugin interface, >>through which the user of the proxy (or their distributor) could >>configure custom behaviour. This could be used to prompt the user for >>confirmation before allowing a screen capture request, or even to >>implement a similar thing for e.g. clipboard access, for which there is >>no support in the Wayland protocol. It could even be used to modify >>surfaces, to implement things like Qubes-style unspoofable coloured >>window borders. > > I am tempted to ask how close it will be to providing a socket for WM > and window decorator implementation (with some suitably limited=20 > compositor as the backend behind the proxy). > > (So basically, defining a scope will be hard, and defining a scope in > a usefully extensible way might be even harder) I don't understand this point. Can you rephrase / expand? >>This approach would allow permissions systems and other custom Wayland >>behaviour to be implemented in a compositor-independent manner. >>Distributions which suppor tseveral compositors could implement >>customisations in a single place, and users of compositors which lack >>security features and the assurances memory-safety can provide against >>untrusted input would gain access to those things. > > That surely sounds good=E2=80=A6 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEH9wgcxqlHM/ARR3h+dvtSFmyccAFAmCpHoEACgkQ+dvtSFmy ccC3tRAAoUsxadS2gUBiNfWjzI6JBBMvjRiVJnhjdB/N5WIbwsJYm9SlKJH69sME CmqZQrbNMN5nmMF9mTpFjG/0x5g4G/7WlQSnzj4zjspGomfH6id7dc9vUNudCHH8 ekdulUm+qj8403FY8I7fll3CwOkFqQ4zJR8gqdEu/HEnl7aOwYBFh2P6y1xE4m8b 3b9Z92N3uqfMGG0WzRZdsCvbf0RLJgvMJz46O9jRNONjB0atjKy9+uqYghymSyLu Fe4A1im5yi5ErYredNo258wB2exklGLagmoWDUUtGq9iTswgfFGU34wvfhBI/tSH O1aCRC60XvdUYBvYtVK0B5ggQH7FTd4fr0/mF2TQPfxVBX6pMHFYtsDZuvRQbWDD qoRfO6aU4KBlXyDAZIUsdu7AJI5CE6vwnWsYJtm4OAKNVlp6KV1w3FMYTu63mvoP ajCiFzxoxHUNtnDRa6MP2m/zUEfszKerN2yDmc8J9giGu7vTOCDKmNyM5InvnNJy oo+Dw9SVj8a7MCHS6B/S/aVZocPVAohcEHZgLCruP6vhmNmVx0o1Gz2VfOsLeLzJ KSJ1uGz+seq8tAi/gAeaTYsTO5a060/tNQpQ5eKVzAygVpLhMBlKidrWesgYD9WG kFU4mV4CL4+ebxys4MUPHXGCI7xGnzlXEwMeiuo4Efi31a4oI6I= =Hmbp -----END PGP SIGNATURE----- --=-=-=--