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.6 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_H4, RCVD_IN_MSPIKE_WL,SPF_HELO_PASS autolearn=unavailable autolearn_force=no version=3.4.5 Received: by atuin.qyliss.net (Postfix, from userid 496) id 49A6BEC8D; Mon, 2 Aug 2021 08:31:20 +0000 (UTC) Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id AF453EC1E; Mon, 2 Aug 2021 08:30:47 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id 9159EEC7B; Mon, 2 Aug 2021 08:30:44 +0000 (UTC) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by atuin.qyliss.net (Postfix) with ESMTPS id 116E7EB85; Mon, 2 Aug 2021 08:30:40 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 7E64C5C010D; Mon, 2 Aug 2021 04:30:38 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 02 Aug 2021 04:30:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h= from:to:subject:date:message-id:mime-version:content-type; s= fm3; bh=CIQmhEyAWHe4e4Tx0+qK5skmL0x/MepNFyOGxIyD7IE=; b=Nb2gS9o7 wkRIMoWvT0R0lv6XKrsqkcg6zG13V0Nv8rVuqxsEaf+z0DOtCHWGixIvnWztAlmy BzJ7gn3GqAgGe+2IbW92J5TzsosoL+OoAzLyooAAsiAiNk0knR1lv2dB4kAMTYAi tghsr6o8iPX6O5DO1ooKfqm+0Mr8XCa3fXEMhKymI39iLaQ1b4gl9VKNInXTC644 Aa5ggUSFvzd7k19v24DZ9q5Jfb6uyx43hUliorMwHKFqwt3jdNI1NyXiPjgBRHlK OkRZKSO+hbUo0rHkiQSkQaElT2p1+6YngKlRJXV/Ne7B2gevQkLS/MCI5Ohx5ePZ o8Rqkqf3j4Jgag== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=CIQmhEyAWHe4e4Tx0+qK5skmL0x/M epNFyOGxIyD7IE=; b=TeE8ggTJjDh7DEfRQPbBtY8dKP4hmfBwuLsZi4/lVYClV TPfdZIXfsLs+ovaqqEAzhKz4N7pJ86mYbiScBhxaotoCv4zlaUviZCbJXYjc8+Ew l4rArCVyl8bOEYZWgHYpAkquFdf1HuJC/awUmGCoaTcCeqF9wjBvlh1YotUKNKmh dxg0SMn0P8WGfPuDogYXMPMX4pZ+xFs6f135qza4mzbiMLkK/1VfppOHqhNcuX/i 8d00f+oqnDKx4U21PKqyzmWMe75jmTYfm4xfpTZIeIOw/JBis0CrIWHCCzkruaYp ZXW+cHPjSvwhZcSGz9d0jsVH8hGx07z3roSaBKlYg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddriedvgddtudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfggtgesghdtreertddttd enucfhrhhomheptehlhihsshgrucftohhsshcuoehhihesrghlhihsshgrrdhisheqnecu ggftrfgrthhtvghrnhepvedvieeuffeifedvfedtvdejhedujeevgfejieektedvtdfhle duheffudejieejnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpfhhrvggvuggvshhk thhophdrohhrghdpshhpvggtthhruhhmqdhoshdrohhrghdpkhgvrhhnvghlrdhorhhgne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhephhhisegr lhihshhsrgdrihhs X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 2 Aug 2021 04:30:37 -0400 (EDT) Received: by eve.qyliss.net (Postfix, from userid 1000) id 47CBF1665; Mon, 2 Aug 2021 08:30:35 +0000 (UTC) From: Alyssa Ross To: devel@spectrum-os.org, discuss@spectrum-os.org Subject: This (Last) Week in Spectrum, 2021-W30 Date: Mon, 02 Aug 2021 08:30:28 +0000 Message-ID: <87zgu0ckpn.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Message-ID-Hash: XUK7Y3SO446XXAGWNBIZ642BBOCESW5E X-Message-ID-Hash: XUK7Y3SO446XXAGWNBIZ642BBOCESW5E 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 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 Hi, it's been a long time since I've done one of these, but so much interesting stuff happened this week, and there's been a bit of renewed interest in the project, that it _really_ needed an update. So here it is. As always when I'm not keeping up with TWiS, this update is limited to only things that happened in the last week, because otherwise it would just be far too long. Wayland ------- A problem I've been thinking about for a long time is Wayland access control. The Linux desktop ecosystem is moving towards access controls for most functionality through xdg-desktop-portal[1] (which sadly doesn't seem to have a website). But it doesn't cover stuff that's part of the core Wayland protocol, like access to the clipboard. And some compositors (wlroots-based ones) provide extra Wayland protocols for things like screenshots. And up to now, Wayland compositors haven't really done any authorization for these potentially dangerous APIs. (All of this is only really meaningful for sandboxed applications -- running in Flatpak or a Spectrum VM or something. Linux isn't really set up to do separation between processes running as the same user without namespaces.) So earlier this week, I posted[2] to the Wayland mailing list with an idea I'd been thinking about for a while[3], which was to place a proxy program in front of the Wayland compositor, that would intercept client->compositor requests and handle access control. I was quickly convinced that a proxy wasn't a good idea, but there was a lot of discussion, and it was really helpful to me figuring out what the right way to do it might be. There are really two problems to be solved here, one of which I hadn't even thought much about. The first is securely identifying a Wayland client. A compositor needs to be able to form the question "Should client X be able to do this?", and to do that it needs to be able to identify a client as client X, and know if it tries to interact with client X later, that it'll be talking to the same client. In a non-virtualized system, the obvious way to do this would be getting the pid of the client from the connection socket and then looking it up in proc(5) to find out executable path, but this approach is fundamentally insecure[4]. The way forward here (and one that would work for Spectrum) appears to be the proposed Security Contexts protocol[5], which would allow a sandbox implementation to provide a security context identifier for a client before handing off the Wayland connection to the client. Once the security context had been set up, it wouldn't be allowed to be modified, so once the sandboxed client was given the connection, it wouldn't be able to change the security context identifier. In Spectrum, the security context identifier here would likely be a unique, user-provided name for the VM, and the security context setup would be done by the virtio wayland implementation in the VMM. The second part of this puzzle is how the compositor should decide whether a client should be allowed to perform a particular operation, like a paste or going fullscreen (which is risky because it might spoof a desktop). There was actually a previous attempt at this a long time ago. libwsm[7] (short for Wayland Security Module) was a library that compositors would have integrated to make authorization decisions. But it wasn't adopted by compositors, and it some things we now know[8] to be bad ideas, like setting policy based on the executable path. It also made compositors responsible for any sort of authorization UI. In my opinion, it's better to have that done by the external piece, so that compositors have as little work to do as possible and therefore authorization is implemented as widely as possible. The compositor could implement an authorization system entirely on its own, but this would be a lot of code for each compositor to write, and it would limit the user to whatever permissions system the compositor came up with, which might not be able to accommodate their needs. (An example of this would be a Spectrum user that wanted to allow pasting between two applications, but not allow pasting between either of those and any other application.) It could also be implemented by having the compositors integrate with something like polkit[6], but compositor authors are reluctant to integrate directly with a single system like that, and even polkit might not support everything that would be desirable in an authorization system. (For example, it might be nice to implement libwsm's concept of a soft allow, where an action is permitted, but a notification is shown so the user is aware it's happened.) So a third solution, suggested by ifreund, a Wayland compositor author, in the Spectrum IRC channel, would be to have a privileged Wayland client that the compositor could ask authorization questions to, with a new protocol. The compositor would know that this particular client should be privileged because it either wouldn't be in a security context, or would be given a special security context identifier known to the compositor ahead of time. Then, implementations of this protocol could do authorization however they wanted, with the only limitation being the questions the compositor was programmed to ask them. I think this is a good way forward, but it'd be important to discuss with more compositor authors before getting to excited about it. Next steps from here with Wayland are: * Figure out what needs to happen to move the security contexts proposal forward. If it needs an experimental implementation, maybe we could help with that? * Inquire about the authorization protocol idea, and see how other compositor offers would feel about it. If there's a generally positive reaction, figure out how to move forward with it. [1]: https://github.com/flatpak/xdg-desktop-portal/ [2]: https://lists.freedesktop.org/archives/wayland-devel/2021-July/041896.html [3]: https://spectrum-os.org/lists/archives/spectrum-discuss/8735ueudel.fsf@alyssa.is/ [4]: https://gitlab.freedesktop.org/wayland/weston/-/issues/206#note_176699 [5]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/68 [6]: https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html [7]: https://github.com/mupuf/libwsm [8]: https://lore.kernel.org/lkml/87r1xplsku.fsf@x220.int.ebiederm.org/ Nixpkgs ------- I created a branch in Spectrum's nixpkgs repository[9] for the long-overdue merge with upstream, did the merge, and posted some patches[10] to spectrum-devel that fix all the builds that broke as a result. I've been letting them sit for a few days hoping for a review. Once that's done, it's time for another chromiumOSPackages upgrade, but that should be pretty easy this time because we're only one version behind. [9]: https://spectrum-os.org/git/nixpkgs [10]: https://spectrum-os.org/lists/archives/spectrum-devel/20210729100928.1965341-1-hi@alyssa.is/ Thanks for keeping up with Spectrum. :) --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEH9wgcxqlHM/ARR3h+dvtSFmyccAFAmEHrSQACgkQ+dvtSFmy ccDGyw/+JhLscK9RIAukogriVu3HBN0POiKKYR0wzyODpCf7zsrCZMDKMtIrVbuF ZqodDl5aHZSlKDc02Nv/7ckpEBEI2oIEW4QoK3zodVbxEq2KAcRkC4nGYOkPGXLW R9RNqn3XJCPzlzjKPtJOonipyxrMdzfLEdavfgtKpiE1MfUXuyYP6DblPWtX/7p1 Wzf3I3i/W1bcTkbsqz1LfmMkESIwxMX6AH/rYH1tuWd9EhIaVIoyc2OwDPYqkZms hGHY3vW8gc81ddyQcZH2f/Trxrh3/eLgAtP/lcT3+hiU9ydJRKULG+Z2wQLnRtg2 ipU0KugUz6ZnsKw3uHGtmWo+LBYiT+L8eN3PmGvKNnJA+fRRoozGFlTw+YNyo5rZ Rn8ry1dOrah9aIa52Jxll1T+BXHWJT8k1v+OaA41YMNOaHc8J6VnovBM1JxiK8SP tMbb22450DAOK6qsYvkNJzq5SZMeDw8xel0uKRu+eUjiligFycW+mbQlO2NXNhuU gyUMYgm8QVxjg69gblr2Qz/JxxMfxXb0aa16Ta7FO6HF7z9pTJSscrUznuqqkDgQ mBGnC9ifcr9ZFT0/wIo309YhtgAf2ZVonUHkaz30cRgPtJMIbiGIKTT68MtvC2NZ YmWYNv2sXeAZbbMUkKffPMGGzRceChHUTc+nthU97/umaKgCEEE= =uuO/ -----END PGP SIGNATURE----- --=-=-=--