Decide which Wayland protocols to expose to guests

[DemiMarie]

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.

• Wayland core — the core Wayland protocol, required (with a few exceptions) from every compositor.
• XDG shell: Required for desktop-style user interfaces.
• Linux DMA-BUF: Allows GPU buffers to be passed to the host, required by Mesa for GPU acceleration.
• XDG decoration: Needed to avoid duplicate decorations.
• Text input: Allows input of languages requring input methods.
• KDE server decoration: used by old GTK versions instead of XDG decoration.

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

• XDG activation: Allows a client to pass focus to another toplevel.
• Linux explicit synchronization (dma-fence): Support for explicit synchronization of GPU work. This is the future of Linux graphics, so it ought to be exposed in the future despite its very limited adoption right now.
• Presentation time: Needed for accurate audio/video synchronization
• Viewporter: Utility protocol; I’m not sure what it is used for but I think it is needed in practice.
• Touchpad gestures.
• Fractional scale.
• xdg-foreign (thanks @puckipedia!): This is needed for portals to work properly, but should probably be partially filtered so that one guest cannot reference a window belonging to the host or another guest.

Safe

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

• KDE Idle
• KDE blur
• KDE contrast
• KDE Slide: allows repositioning windows.
• KDE Shadow: allows shadow control.
• XDG Output: exposes information most clients have no interest in.

Must not be exposed

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

• Session lock: allows locking the screen & displaying arbitrary graphics.
• Xwayland shell: allows arbitrary positioning of arbitrary surfaces.
• Security context: should not be exposed by the compositor to sandboxed clients, so if it is exposed, it means that the compositor thinks the client is not sandboxed.
• Fullscreen shell: allows taking complete control of an output. There may need to be a way for certain programs (such as LibreOffice Impress) to take complete control of certain outputs (such as a projector), but only with user consent. as per @puckipedia this is not needed.
• Foreign toplevel list: allows listing all toplevel surfaces, including ones created by other clients.
• Input method (all versions): allows arbitrary text injection.
• XWayland keyboard grabbing: allows obtaining all keystrokes, must be restricted to Xwayland alone per specification.
• wlr foreign toplevel management: allows acting as a window manager.
• wlr layer shell: allows unrestricted drawing anywhere on the screen with no borders.
• wlr screencopy: allows screen capture.
• wlr gamma control: allows manipulating gamma tables
• wlr input inhbitor: allows preventing input to be sent to other clients (also deprecated).
• wlr output power management: allows controlling power management, probably denial of service only
• wlr export DMA-BUF: allows screen capture
• wlr virtual pointer: allows emulating a pointer device
• KDE AppMenu: allows causing the compositor to make D-Bus requests. It might be possible to proxy this with a D-Bus proxy, but the protocol must not be exposed directly.
• KDE lockscreen overlay: Allows overlaying the lock screen. There might be higher-level interfaces for e.g. VoIP calls, but the protocol itself must be privileged.
• KDE DPMS: allows controlling power management, probably denial of service only
• KDE output management (all versions): allows managing outputs, which is clearly bad even though I cannot think of an exploit right now.
• KDE screencast: allows screen capture.
• KDE server decoration pallete: allows changing server side decoration colors.
• KDE Plasma shell: can be used to implement a window manager.
• KDE Plasma Window Management: can be used to implement a window manager.
• KDE Plasma Virtual Desktop: allows changing virtual desktop.
• DRM lease.

[DemiMarie]

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

[alyssais]

My plan is to ask @puckipedia :P

[puckipedia]

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]

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]

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.