Today, desktop applications can use the unity7 or x11 interfaces or both. The original idea behind these was that
- they were transitional interfaces for legacy user session environments and
- unity7 only could run on x11, so it duplicated the X policy so developers need only specify ‘unity7’
The original idea is we would add interfaces for unity8, mir, wayland, gnome-shell, etc. Because of the time in which snapd involved (ie, we didn’t quite know where we were going: wayland, mir, unity8, gnome-shell, etc) the unity7 interface became a catchall for ‘legacy’ desktop security policy.
In working with this policy and examining the current landscape, I think we should rethink our current plans. Since it is reasonable to assume that most developers want their snaps to work on as many desktops as possible and because we want to provide a path towards a future with non-transitional, secure desktop policy, I propose we:
- group all contemporary Desktop Environment default policy into a new
desktop
interface. Contemporary DE’s are defined to include those that can run without X. The policy shall be defined to be anything that can be reasonably confined[1] with access to common services (eg, gmenu). This interface will be autoconnected - display server policy shall not be duplicated in the
desktop
interface. Instead, snap developers specify which display server the snap is expected to work. In practice, they mightplugs: [ desktop, mir, wayland, x11 ]
. This is reasonable since developers would need to program their applications to work under different display servers and this declares where the snap is expected to work - break out accessibility into
desktop-accessibility
instead of having it included indesktop
. a11y was not designed for application isolation and allows sniffing and injecting input events. The deficiencies of a11y were recently acknowledged within GNOME and, aiui, flatpaks currently can’t access the accessibility bus. We will allow specifying it as (possibly manually connected)[2] interface but as the security story improves upstream wrt accessibility, we can always add it to thedesktop
policy - continue to have legacy DE policy in the unity7 interface, including duplicated x11 policy so that existing snaps continue to work like always
With the above, we strive for desktop
to be non-transitional, safe security policy and only add safe accesses to it. Unsafe/transitional accesses are broken out into other interfaces, like desktop-accessibility
and password-manager-service
. Since applications need to be coded to work with different display servers and because we want users to be able to disconnect x11, display servers are also in their own interfaces instead of duplicated in the desktop
interface.
snapcraft.yaml wanting to target today’s legacy DEs remains unchanged[3]:
apps:
foo:
plugs:
- unity7
- x11
snapcraft.yaml for applications that want to add the new contemporary DE policy to their existing legacy DE policy simply add desktop
and optionally desktop-accessibility
and wayland
:
apps:
foo:
plugs:
- unity7
- x11
- desktop
- desktop-accessibility
- wayland
The above allows the snap to work everywhere, but the security-conscious user running a wayland desktop can snap disconnect foo:x11 && sudo snap disconnect foo:unity7
.
snapcraft.yaml for applications expected to work only on contemporary DEs (eg, gnome-shell, plasma, sway) that may have an X fallback (eg, gnome-shell, plasma) simply adds the new desktop
and desktop-accessibility
interfaces:
apps:
foo:
plugs:
- desktop
- desktop-accessibility
- wayland
- x11
The above allows the snap to work under X or Wayland, but the security-conscious user can snap disconnect foo:x11
. In the future, when X11 is gone snap developers just drop x11
.
I believe the approach outlined in this topic allows us to remain compatible with all existing snaps, have reasonable snapcraft.yaml declarations for snap developers, provides a path forward for non-transitional and secure desktop policy and at the same time allows users to experiment today with disconnecting transitional policy.
[1] reasonably confined because it is not expected that every desktop DBus session service is currently coded with application isolation in mind. In other words, some things are still transitioning
[2] we could consider this an auto-connectable transitional interface (eg, like gsettings). Because it is broken out into its own interface, a security-conscious user could always disconnect it.
[3] as it happens, even though unity7 duplicates the policy in x11, most developers specify both (another reason to not duplicate with the new interfaces)