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 C00EF118F4; Sat, 22 May 2021 13:39:15 +0000 (UTC) Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id F175C11936; Sat, 22 May 2021 13:39:03 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id 4DE7B11932; Sat, 22 May 2021 13:39:01 +0000 (UTC) Received: from smtp48.i.mail.ru (smtp48.i.mail.ru [94.100.177.108]) by atuin.qyliss.net (Postfix) with ESMTPS id 34AAA11931 for ; Sat, 22 May 2021 13:38:56 +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=hc+GByzu4WtPlHwQRezDJqUd3RjalkY+BqESpvKOC6k=; b=rfInHbWDmrnTmabcu03YmQBH6isHFexPVp+yXZrryV37uTLaOtbIfVfRoiiTe55qbWbYIbJgO2J/u0Beb2jd/3v8WNdHYEq7kbB8TTO14x74IYrAd++dC2kXjPb3zm0zq8moImBc4IZcxk8rsJYnPeGLROPHT5abJ/JgU7HDY8s=; Received: by smtp48.i.mail.ru with esmtpa (envelope-from <7c6f434c@mail.ru>) id 1lkRq9-0004ND-Us; Sat, 22 May 2021 16:38:54 +0300 Date: Sat, 22 May 2021 15:45:51 +0200 From: Michael Raskin <7c6f434c@mail.ru> To: hi@alyssa.is, discuss@spectrum-os.org Subject: Proxying Wayland for untrusted clients X-Mailer: cl-smtp (SBCL 2.1.2.nixos) IN-REPLY-TO: <8735ueudel.fsf@alyssa.is> REFERENCES: (<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: smtp48.i.mail.ru; auth=pass smtp.auth=7c6f434c@mail.ru smtp.mailfrom=7c6f434c@mail.ru X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD91B019B01C53E51AF388A0BB768BC527FF0271862FFB192DD00894C459B0CD1B96DD479D78A8BFD26A9CE6F194AEFBCE980CDEDF55E0354AC838627A7128B43D1 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE706EA9E10470DC775EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006375AC38C7EC4509C8B8638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D881366D99E3D48C292D336BB83E1B62CA117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC9FC99A4BA45EE8B4A471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F4460429728776938767073520B1593CA6EC85F86D6FD1C55BDD38FC3FD2E47CDBA5A96583BA9C0B312567BB2376E601842F6C81A19E625A9149C048EEB28585415E75ADA9436E4CC186B5AB2DD8FC6C240DEA7642DBF02ECDB25306B2B78CF848AE20165D0A6AB1C7CE11FEE3B355ED1E20F5346A03F1AB874ED89028C4224003CC836476EA7A3FFF5B025636E2021AF6380DFAD1A18204E546F3947CB11811A4A51E3B096D1867E19FE1407959CC434672EE6371089D37D7C0E48F6C8AA50765F7900637742364C369F68A8BEFF80C71ABB335746BA297DBC24807EABDAD6C7F3747799A X-C1DE0DAB: C20DE7B7AB408E4181F030C43753B8186998911F362727C4C7A0BC55FA0FE5FCD8B2D445FE866AA5B05E633A4D69E4A75D8BF07ED7773914B1881A6453793CE9C32612AADDFBE0614D5AFD0B08438872C581CE5390BD6510ADF10D55CAE46FEDBDBA34C8DF405E9A04EBA3D8E7E5B87ABF8C51168CD8EBDBC8B02E85A1983BE4DC48ACC2A39D04F89CDFB48F4795C241BDAD6C7F3747799A X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D346E67BC984B8ABCB5ED9975CA4D4631296B53EF70042274CF86137730D878E7A486002C0ED5F300571D7E09C32AA3244CB54768D8FFEB0814D55FF96B6ED5EBD7B018FE5BB746DCD183B48618A63566E0 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojbL9S8ysBdXhXV54UPFcvLeTrNqQxjRpF X-Mailru-Sender: 35B75D2CAA45F3130BB9478DFF6488F2F7A7B79AD4966692808B793D27FB752286F1700BB67B7510286CF1FB17F948F1E66B5C1DBFD5D09D5BDABB69D8D2C502C003600472B6CB9B67EA787935ED9F1B X-Mras: Ok Message-ID-Hash: 4NKSIK74MKWQK6HBPT3EH6VR6L2O6SLV X-Message-ID-Hash: 4NKSIK74MKWQK6HBPT3EH6VR6L2O6SLV 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 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) >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 deprived of what Xorg server did for everyone. >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? >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) >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