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=-2.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MALFORMED_FREEMAIL, MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=no autolearn_force=no version=3.4.5 Received: by atuin.qyliss.net (Postfix, from userid 496) id E53D212813; Sat, 22 May 2021 16:12:01 +0000 (UTC) Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id AF66312768; Sat, 22 May 2021 16:11:46 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id 0B43112767; Sat, 22 May 2021 16:11:44 +0000 (UTC) Received: from smtp33.i.mail.ru (smtp33.i.mail.ru [94.100.177.93]) by atuin.qyliss.net (Postfix) with ESMTPS id 52DE812765 for ; Sat, 22 May 2021 16:11:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail3; h=Message-Id:Content-Transfer-Encoding:Content-type:Mime-Version:REFERENCES:IN-REPLY-TO:Reply-To:Subject:Cc:To:From:Date:From:Subject:Content-Type:Content-Transfer-Encoding:To:Cc; bh=o1idymx33+fJLGgC7KzEveHnyd7B8WhownSZHIlBevw=; b=dqjoT0XiBW6S/PTfaJ5D3AT7DNZUXhAKpIi8BpHYM1uaDfNGznbrotxJbv7ZOKKTSBl14BuRP6JH7aHDU/Eb4AUsYMFEo93y3qZYIifk3cS93T95vFT37Fpl9aU8R6aBKLkx0j2GSPgfYAgFJO/0RJo1NwBoDd2pXQtJegZ5Khk=; Received: by smtp33.i.mail.ru with esmtpa (envelope-from <7c6f434c@mail.ru>) id 1lkUDz-0006pI-Pa; Sat, 22 May 2021 19:11:40 +0300 Date: Sat, 22 May 2021 18:18:37 +0200 From: Michael Raskin <7c6f434c@mail.ru> To: hi@alyssa.is, discuss@spectrum-os.org Subject: Re: Proxying Wayland for untrusted clients X-Mailer: cl-smtp (SBCL 2.1.2.nixos) IN-REPLY-TO: <87h7iuztz4.fsf@alyssa.is> REFERENCES: (<87h7iuztz4.fsf@alyssa.is> . <87h7iuztz4.fsf@alyssa.is> <8735ueudel.fsf@alyssa.is> <8735ueudel.fsf@alyssa.is> ) Mime-Version: 1.0 Content-type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-Id: Authentication-Results: smtp33.i.mail.ru; auth=pass smtp.auth=7c6f434c@mail.ru smtp.mailfrom=7c6f434c@mail.ru X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD91B019B01C53E51AFA94C0B24B2C939D4C80F0683D6F6F7C600894C459B0CD1B949C0B4D9071DC89E675D212204EBCCC8F7D523755E2FECAFF600E77B63AAB791 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE73A0E02362971E860EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006378D08D652E28591A78638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D835B7DE9CC506E0601095C198A963AE9A117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC60CDF180582EB8FBA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F44604297287769387670735201E561CDFBCA1751FF04B652EEC242312D2E47CDBA5A96583BA9C0B312567BB2376E601842F6C81A19E625A9149C048EEB1593CA6EC85F86D2D242C3BD2E3F4C64AD6D5ED66289B52698AB9A7B718F8C46E0066C2D8992A16725E5C173C3A84C36F560EC7065075D7BA3038C0950A5D36B5C8C57E37DE458B0BC6067A898B09E46D1867E19FE14079C09775C1D3CA48CF3D321E7403792E342EB15956EA79C166A417C69337E82CC275ECD9A6C639B01B78DA827A17800CE73CC03873634D8B89731C566533BA786AA5CC5B56E945C8DA X-B7AD71C0: AC4F5C86D027EB782CDD5689AFBDA7A24209795067102C07E8F7B195E1C97831A376F81477FB50A4285D1CF7EB47FA2E X-C1DE0DAB: 0D63561A33F958A5D92B0359F179EED74DFA7CF01701123F58D9131F9745240ED59269BC5F550898DBE8DEE28BC9005CC068A6029CA466BAE87EB34E062A15A47BCC32E49D76C4CC5DF1C2DF01CE7211886A5961035A09600383DAD389E261318FB05168BE4CE3AF X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D340297C696F996E384ACA2B68CC18B90F9AB5960B1F6FE640C017D2A98D8AB51A0607E876A6D999CAA1D7E09C32AA3244CAE3F688C69D35F51DFF4F476C62D2F44E3D93501275E802F83B48618A63566E0 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2bioj3CIvDNz8QqBECPXAbSQb7w== X-Mailru-Sender: 35B75D2CAA45F3130BB9478DFF6488F2BFB0C0B55CDEF6233519255FC39FBE985820E56495D10B2E286CF1FB17F948F1E66B5C1DBFD5D09D5BDABB69D8D2C502C003600472B6CB9B67EA787935ED9F1B X-Mras: Ok Message-ID-Hash: UBA74WOGRLL7BI33E7ROPKS6YOQ73OCO X-Message-ID-Hash: UBA74WOGRLL7BI33E7ROPKS6YOQ73OCO X-MailFrom: 7c6f434c@mail.ru 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 Reply-To: 7c6f434c@mail.ru List-Id: General high-level discussion about Spectrum Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: >>>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 th= e >>>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 i= t >> 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. >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.) Assuming the client does not use the protocol extensions to control the=20 request, presumably black rectangle immediately and a permission dialog=20 from WM to the user, then the capture suddenly getting real data. Single-window capture depends on whether the client can handle capture resize, if yes, no problem (capture the generic =C2=ABwindow=C2=BB in the client, get black box while the user picks the true target). Otherwise there=20 might be some juggling indeed. >> =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 standards, and it seems to crash noticeably often with reasonably well-behaved clients, so just a protocol compliance filter would not be enough. >>>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 aroun= d >> 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. >>>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.