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 87FEE12DB1; Sat, 22 May 2021 17:22:36 +0000 (UTC) Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 6E24A12D1C; Sat, 22 May 2021 17:22:23 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id 6A6FA12D84; Sat, 22 May 2021 17:22:20 +0000 (UTC) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by atuin.qyliss.net (Postfix) with ESMTPS id 07C9F12D13 for ; Sat, 22 May 2021 17:22:17 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id ED7C65C00A3; Sat, 22 May 2021 13:22:15 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sat, 22 May 2021 13:22:15 -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=wXycctoActPefi3ygAEQMGHQza qrlWUpNwryV77XdPI=; b=WB0sqFak1JNo8Pgq/cfpm/G7f/GFxOXNX6hxZkUqFX F9f78siqC0Q0/Y2h8O3jPiPHFdr9sTCd3GLmYwnyutg5fMsEN8UGhSheGCgTuO27 YuF88kr2JPr8LmuO3J8IRO01SYQAPkK9ULIFuQU0nCHNcWM+1p26G2ZvXAvgn9j4 t/dq7/OLOLXvw5k9XP837RiIqW/bWCGcHmtirF7YyCnNhS6SNXhrLR2PVJvRf9Dk o1BAW4BsSEQBrM2PG+/HSAW/AyA6Cw8L/Ca7+IE9D+zkXPFrMZ4eu6ICq9ivh5/m KIvNgIqAme2j9kDYkGxEiHDQwNYrZp48X9W9xk8XeeKA== 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=wXycct oActPefi3ygAEQMGHQzaqrlWUpNwryV77XdPI=; b=mDZIVwT1JAAnEWgnsL7W9k efMy/vHl35AtK9I587r70YYBSKiv/d40CPWmVCEyWo3RRg20qsiKJtm3XUUA6vOp hl4u/i6S5zuk92Lq4L9d2AHhbc+uQzrnTd6v/zjiWTYDuBUNuGRDlX9ycibsWtFZ LODJfCpBvZFLHyqu2QZWZ9YwVrbKfsxdXZvwwakTrOJumL3Q08CTBtIj1N0ZOM/1 LL1TF4IL9m7ex8XX47TVq7eCbW57RAaOfmY4ceWWgdRHoqMeCFj+bXK7xDoNpw6T aLnNoChghOr4NubjtJ5C0ulSydhROHvlLDfA9FR2gloWZpbpjMKPCQ2bd46JtkkA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdejhedguddufecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufgjfhffkfggtgesghdtre ertddtjeenucfhrhhomheptehlhihsshgrucftohhsshcuoehhihesrghlhihsshgrrdhi sheqnecuggftrfgrthhtvghrnhepffduudffueffgeehieegjedtkefhudehheefudehle fftedtkeeitdegfefgleehnecukfhppeegiedrkedtrddufeekrdejfeenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehhihesrghlhihsshgrrd hish 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 13:22:14 -0400 (EDT) Received: by x220.qyliss.net (Postfix, from userid 1000) id 4BBA8EE6; Sat, 22 May 2021 17:22:12 +0000 (UTC) From: Alyssa Ross To: 7c6f434c@mail.ru, discuss@spectrum-os.org Subject: Re: Proxying Wayland for untrusted clients In-Reply-To: References: <87h7iuztz4.fsf@alyssa.is> <87h7iuztz4.fsf@alyssa.is> <8735ueudel.fsf@alyssa.is> <8735ueudel.fsf@alyssa.is> Date: Sat, 22 May 2021 17:22:07 +0000 Message-ID: <87eedyznsw.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Message-ID-Hash: ILTTWQX4C7AYD4YJVLOGGTN2WETT3QXT X-Message-ID-Hash: ILTTWQX4C7AYD4YJVLOGGTN2WETT3QXT 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 = client 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! > > Considering how much works fine in Xvnc which kind of lacks half the > extensions, and considering that all the bad hardware stuff now needs to > be handled in each compositor, it is unclear how much worse it would=20 > actually be. > > So OpenGL-first design sounds like the real reason for all the mess. What do you mean by bad hardware stuff? Most hardware should be handled by KMS and libinput, shouldn't it? >>> =E2=80=A6 unsurprisingly, as these are typically WM teams who are now d= eprived >>> 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. > > Yes, but it seems memory-unsafe even by the =C2=ABcareful C=C2=BB standar= ds, and > it seems to crash noticeably often with reasonably well-behaved clients, > so just a protocol compliance filter would not be enough. My experience with wlroots has been that when it crashes, it's because of quirks with monitor state and stuff, not anything from the Wayland protocol. Have you had a different experience? Another thing the proxy would be really cool for that I didn't mention before is debugging. Potentially you could even record and replay Wayland messages, which would help with any crash that was from Wayland. >>>>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. > > Looks like for wl_shm the client creates and shm object and sends FD to > the server, then both sides mmap from there. Given that one could cook=20 > an FD with approximately arbitrary combination of properties, I guess > some care should be taken about this, too. Hmm, yes, looks like you're right. I wonder how virtio wayland can work the way it does, then... But yes, that is something we could validate. >>>>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? > > Well, you start describing a proxy that is basically =C2=ABonly valid=20 > messages pass=C2=BB and that's it, then add that it could also implement = some > more functionality. Then you say plugins for policy-heavy functionality. > (I guess at that point the natural next step is a socket so that > safety-handling and user logic could be in different processes) > > This sounds like a recipe for scope creep, although it might also be > good as a single well-vetted Thing being safety-critical and a lot of=20 > policy decisions being pushed to restartable and=20 > functionality-restricted separate processes is actually better than the > current recommended approach to Wayland compositors. > > If you want to try pushing the project to freedesktop, I suspect it is=20 > a good idea to define how much scope you want to include into the pitch. > Although apparently they don't have any objections to hosting software > with heavy scope creep, when reaching for a high profile, it is a good > idea to set internal expectations before having to manage external ones. I actually think the scope is fairly limited? 1. Receive request 2. Validate request 3. Asynchronously run request through plugins (you're right that external processes are probably a better idea, although I worry about complexity and performance). 4. Forward request to compositor --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEH9wgcxqlHM/ARR3h+dvtSFmyccAFAmCpPcEACgkQ+dvtSFmy ccB9oQ//Q6gPJ7z2K8QsE9sjmkiKeOECt5S+6yO/xQE0B7Uchhagg31+pmalKZiJ wVP442TB35ykjtXK2N1UQAFoJMUry4LAmxcROolJ9vhFLTExse08/6nsDd3d1hj/ BXV+ZkneHCzcPxdYuG+H0NFBxiEIwMcCOTBNEebhAyyNirG8QGoK6iuNdSJDKUr4 bFzoZRKosUgmukmmUDojFPC/IyqWHMV14HI8NYyukGW5TvtUy2ZM0Em2CYCja9Dh Kq1VpdEaYgbUeudi0h+KnUEnxW4jC2dEKm5q59D3zTWNR2Kq/oD21tDUoD61tP0m 1T9oyJR+jDMZoO3AOpZjwUW5OGMCQCzDtDd6v4zhcxt9VnLqsONeIboDhSyPW2e0 r6N7EG+2MjEMQLa2VQa1T8z4o95FTJKaAyQkkq7JKSU99hPQeLzTvqYXePhx9gDq uwsKmbBJmekVqJIxlljqI8Grsu/p8LzFVP0cY/uiP6hy8rWqdkyUBH6IJN4DysDD 7nS5s8yK4QLjqD1Zvnm3kuO3pDmxko41ptlQ4AGIW6RyEQoL5rOErld7QGB0kbc/ JF2ZSnJeT91FUSN5e6x0SvRvd1+cB2hLE1ewwe6/+i3HRXoaZSR5XKOoA9x2KtzC PN+f0kOICkNp1fdu63eGEiFd7RPXIy02rNg3PPEr+2tJdv/koMo= =rdVv -----END PGP SIGNATURE----- --=-=-=--