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 C8CA1132F5; Sat, 22 May 2021 18:49:53 +0000 (UTC) Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 20CC9132B0; Sat, 22 May 2021 18:49:37 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id 6944D13232; Sat, 22 May 2021 18:49:35 +0000 (UTC) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by atuin.qyliss.net (Postfix) with ESMTPS id 3E661132A9 for ; Sat, 22 May 2021 18:49:31 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 7D2015C009F; Sat, 22 May 2021 14:49:30 -0400 (EDT) Received: from imap35 ([10.202.2.85]) by compute4.internal (MEProxy); Sat, 22 May 2021 14:49:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ajanse.me; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm3; bh=RlSk0 4bl3jIRdSEJO5Te2nOwsMh/Wf3hdORoa1UoiqI=; b=uAbauV43NGd/j+kUONeKQ OrEHrE3JBR8JFvjZiWau59a2amFJDOBSIR85EEPcRZMb/EgSEE9/Xo84j4/3ijUz 6CXnqu3hD2sn5sApoDIHxvPVapM0VjmaJRhzzAGMskwZ2OgocH8mY8HcfERjnqQb nMYRvEY9is0wfnSNW7vRO6IDkOOr87uXaGgdEgQ0MMaxPEbqABD3qWF4qDbP0tK6 E4pvNo0VhJ5b6ajVpRmbbWuy7K790q0x7ZSgoNuWJR/tEsDEhxccszA6UpW8o8U4 z1ddz/wntFc3e3Gfv+qnPL8CBl8xlv+H/e4ByyZpJNS/dsGuhnnx1pr8ClLHe31S g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=RlSk04bl3jIRdSEJO5Te2nOwsMh/Wf3hdORoa1Uoi qI=; b=BFrhLF8EmxkxXyrp0JiT2IIR/U1Ze0qu/dwUrm61tUTGyAL7eDPTaUoCo 1AiE3HO/aCbExZ9q79aEtxqKzEo0JCGlPYWhbUBn9AHaCBO1XoXwlvCaOK2zlxmU g/kbyqijqeoKs+45D8fjfZZv6F43oCqJipHtHb9zdGlkGDbMiF9UEDOPoKBxoMnz kT5DhckGDgGRi/nvoCzHDwpzFIzWlbP9QYAMPRh2SG7jvuM+RNtT/SbKdPotV8tv zX77/e9p6K25PHCawy9ZE2NQvMXHtjW7Ii1rfa9exDVyugCzfvBqzMdY37yjyAA4 XslavoGng5dPnNTXRc+kV658fuSzg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdejhedgudefvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgse htqhertderreejnecuhfhrohhmpedftegrrhhonhculfgrnhhsvgdfuceorggrrhhonhes rghjrghnshgvrdhmvgeqnecuggftrfgrthhtvghrnhepffeifeefheekueeivdffvdevte ekudelhfetfeejgeeiiefhvdekueffvdejtefhnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomheprggrrhhonhesrghjrghnshgvrdhmvg X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9C6F115A0066; Sat, 22 May 2021 14:49:29 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-448-gae190416c7-fm-20210505.004-gae190416 Mime-Version: 1.0 Message-Id: In-Reply-To: <87eedyznsw.fsf@alyssa.is> References: <87h7iuztz4.fsf@alyssa.is> <87h7iuztz4.fsf@alyssa.is> <8735ueudel.fsf@alyssa.is> <8735ueudel.fsf@alyssa.is> <87eedyznsw.fsf@alyssa.is> Date: Sat, 22 May 2021 11:48:59 -0700 From: "Aaron Janse" To: "Alyssa Ross" , 7c6f434c@mail.ru, discuss@spectrum-os.org Subject: Re: Proxying Wayland for untrusted clients Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 5J2HVAHGFCLIELVJFX2EAQOCT7CZ7UXE X-Message-ID-Hash: 5J2HVAHGFCLIELVJFX2EAQOCT7CZ7UXE X-MailFrom: aaron@ajanse.me 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: 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: > This proposal turns the overall system of policy enforcement from what= > is currently a nice single centralized component (the compositor) with= > global observation, total visibility, total control, and nice > non-distributed-system guarantees on message ordering, delivery, etc. > into a decentralized and distributed system without those guarantees, > subject to all manner of race conditions, etc. This makes it much > harder to guarantee that intended policies are indeed enforced in the manner expected. How would the new system be distributed? My understanding is that it wou= ld just be a single process alongside the compositor. > I actually think the scope is fairly limited? Agreed, and I don't see a way to implement Spectrum without something li= ke this. At a bare minimum we'd need a proxy for window decorations, unl= ess we feel comfortable forking an existing window compositor. I'm on mobile so I can't quote easily (I also have trouble reading hard-= wrapped emails here), but we do have to place trust somewhere, and writi= ng our own compositor would be too difficult, so it makes sense to have = a simple parse/encode system if only to prevent special extensions that = we don't recognize. - Aaron On Sat, May 22, 2021, at 10:22 AM, Alyssa Ross wrote: > Michael Raskin <7c6f434c@mail.ru> writes: >=20 > >>>>One of the benefits that Wayland is supposed to have over X11 is > >>>>security. A Wayland application isn't supposed to be able to reco= rd the > >>>>screen without user permission, for example. But in most composit= ors, > >>>>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 permissi= ons=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 need= s 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.= >=20 > What do you mean by bad hardware stuff? Most hardware should be handl= ed > by KMS and libinput, shouldn't it? >=20 > >>> =E2=80=A6 unsurprisingly, as these are typically WM teams who are = now deprived > >>> 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 st= andards, and > > it seems to crash noticeably often with reasonably well-behaved clie= nts, > > so just a protocol compliance filter would not be enough. >=20 > 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? >=20 > 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 Waylan= d. >=20 > >>>>To solve these problems, I propose a proxy program that sits betwe= en > >>>>Wayland clients and the compositor, in the same privelege domain a= s the > >>>>compositor. The proxy would decode and re-encode every Wayland re= quest > >>>>(client->compositor message), and would discard any request it did= n't > >>>>understand. This would mitigate the problem of a large, privilege= d > >>>>program written in a memory-unsafe language being exposed to untru= sted > >>> > >>> 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, t= o > >>the client? IIRC this was the reason virtio wayland can work when i= t > >>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 co= ok=20 > > an FD with approximately arbitrary combination of properties, I gues= s > > some care should be taken about this, too. >=20 > Hmm, yes, looks like you're right. I wonder how virtio wayland can wo= rk > the way it does, then... But yes, that is something we could validate= . >=20 > >>>>no support in the Wayland protocol. It could even be used to modi= fy > >>>>surfaces, to implement things like Qubes-style unspoofable coloure= d > >>>>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 vali= d=20 > > messages pass=C2=BB and that's it, then add that it could also imple= ment some > > more functionality. Then you say plugins for policy-heavy functional= ity. > > (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 o= f=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 pi= tch. > > Although apparently they don't have any objections to hosting softwa= re > > with heavy scope creep, when reaching for a high profile, it is a go= od > > idea to set internal expectations before having to manage external o= nes. >=20 > I actually think the scope is fairly limited? >=20 > 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 abo= ut > complexity and performance). > 4. Forward request to compositor >=20 > Attachments: > * signature.asc