QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
538 stars 48 forks source link

Decide which Wayland protocols to expose to guests #8990

Open DemiMarie opened 8 months ago

DemiMarie commented 8 months ago

How to file a helpful issue

Qubes OS release (if applicable)

Design decision should be done before R4.3, feature might not ship by then.

Brief summary

Not all Wayland protocols are safe to expose to a VM. For instance, wlr-layer-shell allows drawing anywhere on the screen with no borders. However, a subset of protocols must be exposed to a VM so that Wayland applications in the VM can work. This task is to decide which protocols should be exposed.

The list below is preliminary. Comments as to which protocols should and should not be exposed are encouraged.

Must be exposed

These protocols are absolutely required to have a basic functioning desktop that supports server-side decorations, GPU acceleration, and languages requiring complex text input.

Should be exposed

These protocols provide features used by many applications, or which provide very significant benefit to applications used by a substantial number of people. This benefit is judged to be worth the risk

Safe

These protocols can be exposed, but might not have a strong reason to expose them.

Must not be exposed

Exposing any of these to a guest is a security vulnerability, unless otherwise specified.

DemiMarie commented 8 months ago

Paging @alyssais because Spectrum’s security requirements are identical to ours in this area.

alyssais commented 8 months ago

My plan is to ask @puckipedia :P

puckipedia commented 8 months ago

Some notes on this list:

The KDE/wlr screencast should be indirectly exposed (thru something desktop-portal compatible); appmenu similarly (because it involves the same passthru as the StatusNotifierItem)

DRM lease is safe to pass thru but useless in the case of virtio-gpu (it's used to get direct access to a GPU's connector/output, e.g. for VR compositors that need extremely low latency)

zwp_fullscreen_shell_v1 can be skipped, as it's an alternative shell used in compositors that do not need full desktop-style behavior (e.g. cars, kiosks); note that xdg_shell itself has a set_fullscreen which requires a wl_output handle.

I'd highly recommend exposing xdg-foreign tho possibly slightly privileged); it allows e.g. desktop portals, or other applications that received a special handle to the window, to create popups as child of another process's window (this is how file open dialogs work in portals; they're separate programs!)

DemiMarie commented 8 months ago

Some notes on this list:

The KDE/wlr screencast should be indirectly exposed (thru something desktop-portal compatible); appmenu similarly (because it involves the same passthru as the StatusNotifierItem)

Appmenus involve com.canonical.dbusmenu, and the main C implementation of that in GLib is not at all robust — I got it to fail an assertion simply by making a mistake in the protocol implementation.

DRM lease is safe to pass thru but useless in the case of virtio-gpu (it's used to get direct access to a GPU's connector/output, e.g. for VR compositors that need extremely low latency)

Yeah, that would be a severe problem for Qubes OS — it would allow bypassing window borders, which would be a security vulnerability.

zwp_fullscreen_shell_v1 can be skipped, as it's an alternative shell used in compositors that do not need full desktop-style behavior (e.g. cars, kiosks); note that xdg_shell itself has a set_fullscreen which requires a wl_output handle.

Makes sense. In Qubes OS the set_fullscreen call will need to be failed or emulated.

I'd highly recommend exposing xdg-foreign tho possibly slightly privileged); it allows e.g. desktop portals, or other applications that received a special handle to the window, to create popups as child of another process's window (this is how file open dialogs work in portals; they're separate programs!)

Will do! Should be easy (though not strictly necessary) to ensure that a VM cannot use any handle that it did not export itself.

DemiMarie commented 8 months ago

ext-placement should certainly be exposed, so that multi-window applications can work well. Not every compositor will implement it, but if the compositor does implement it, VMs should be allowed to use it. The protocol itself includes protection against windows overlaying e.g. the menu bar that XFCE puts at the top of the screen, so there are no security concerns.