Skip to content

RFC: Put up artificial barriers for screenshot, screen share and similar APIs

Problem statement

Some APIs in GNOME Shell and Mutter are intended to be used within the GNOME platform to implement various features, such as taking screenshots or recording the screen, implementing remote desktop services, implementing portals, binding keys, setting up the monitor configuration etc.

More and more, these internal APIs are used by third party applications to bypass sandboxing restrictions. The reason for this can several:

  • Developers might be unaware of the "private" nature of these APIs

  • Developers decide to use these APIs despite their private nature due to their ability to bypass the sandboxing technologies and implement features more similarly to how X11 worked. Doing this is trivial in e.g. flatpak, and currently has no implications on how secure an application is presented to be. gnome-software#1111 (closed) intends to partially improve the presentation issue, but it will still remain an issue, even with proper presentation.

The end result is that portals are often bypassed, and non-portable unstable GNOME-only private APIs are used instead, with little no none incentive to use more appropriate APIs. When (not if) we choose to change these API's, any application that depend on them will also likely break. Overall, it's not a sustainable situation.

Potential solution

Similar to how the "introspect" API is "guarded" against incorrect usage, an alternative is to have a hard coded "allow list" per API, based on D-Bus names. For example, org.gnome.Shell.Introspect is currently limited to org.freedesktop.impl.portal.desktop.gtk, and similarly, org.gnome.Shell.Screenshot could be limited to org.gnome.SettingsDaemon.MediaKeys, org.gnome.Screenshot, and org.freedesktop.impl.portal.desktop.gtk; org.gnome.Mutter.ScreenRecord and org.gnome.Mutter.RemoteDesktop could be limited to org.freedesktop.impl.portal.desktop.gtk and org.gnome.RemoteDesktop, and so on. This would effectively block sandboxed applications from these APIs even if they opened up the same sandbox holes, and would make it less convenient for non-sandboxed applications.

Limiting impact/annoyance

It is still very valuable to be able to use these APIs without any artificial blockage, for example for development or debugging purposes. A potential solution for this is to disable the "allow lists" using a setting. Currently org.gnome.shell introspect is a global toggle for the introspection API, and it could be expanded to include also other APIs, or a new setting could be added. A status menu icon could be added similar to the "screen is shared" icon, to indicate that the security bypass mode is enabled.