general high-level discussion about spectrum
 help / color / mirror / Atom feed
* This (Last) Week in Spectrum, 2021-W30
@ 2021-08-02  8:30 Alyssa Ross
  0 siblings, 0 replies; only message in thread
From: Alyssa Ross @ 2021-08-02  8:30 UTC (permalink / raw)
  To: devel, discuss

[-- Attachment #1: Type: text/plain, Size: 7015 bytes --]

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. :)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2021-08-02  8:31 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-02  8:30 This (Last) Week in Spectrum, 2021-W30 Alyssa Ross

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).