Security policy request: sandboxed and unsandboxed apps on AppCenter

[aral]

Problem

Currently, there is confusion about whether or not unsandboxed apps are allowed on the elementary OS AppCenter.

This stems from a historic misunderstanding of what constitutes an unsandboxed Flatpak app which is basically any app that has --filesystem=home or above permissions. This is the level of permissions necessary for a malicious app to escape its sandbox and thus the level of permissions at which an app should be considered unsandboxed.

This leads to confusion where a new unsandboxed app can be refused a listing on AppCenter (e.g., see https://github.com/elementary/appcenter-reviews/pull/225) whereas a cursory review reveals that are already unsandboxed apps on the AppCenter: https://gist.github.com/aral/5b283d020bab878ca8b2cc83bc66b88d

Proposal

• Document that --filesystem=home and above permissions in a Flatpak app means that the app is unsandboxed.
• Write a policy regarding whether unsandboxed apps are accepted on AppCenter.
• Label apps as sandboxed or unsandboxed accordingly in AppCenter.

There are valid use cases for having unsandboxed apps on AppCenter (one example is a developer tool like Comet – https://comet.small-web.org, AppCenter review details in pull request linked above) and it is my personal opinion that they should be included.

If, however, it is decided that unsandboxed apps are not included in AppCenter, there needs to be a review of existing apps so that unsandboxed ones are removed.

Gotchas to avoid

In terms of whether an app is sandboxed or not, it is important to understand that what matters is whether it has --filesystem=home permissions. Anything above this (e.g., --filesystem=host) is no more or less sandboxed.

Other considerations

While defining whether an app is sandboxed or not, we also have to take into consideration that elementary OS currently uses X11, not Wayland. So any app that uses X11 isn’t really sandboxed and we should decide how this is communicated so as not to create a false sense of security (see prior art, below).

Prior Art (Optional)

See elementary/appcenter-reviews#360

[aral]

Related: https://github.com/elementary/appcenter/issues/1012

[aral]

Resources:

• https://blogs.gnome.org/alexl/2017/01/18/the-flatpak-security-model-part-1-the-basics/
• https://blogs.gnome.org/alexl/2017/01/20/the-flatpak-security-model-part-2-who-needs-sandboxing-anyway/
• https://blogs.gnome.org/alexl/2017/01/24/the-flatpak-security-model-part-3-the-long-game/
• https://flatkill.org (and https://flatkill.org/2020/)
• https://theevilskeleton.gitlab.io/2021/02/11/response-to-flatkill-org.html
• https://ludocode.com/blog/flatpak-is-not-the-future#security
• https://blog.tingping.se/2019/10/06/hardening-flatpak-permissions.html

[aral]

Note: Looks like the implementation is GNOME Software tackles the issue of communicating the sandbox limitations and could be implemented in the elementary OS AppCenter:

Source: https://theevilskeleton.gitlab.io/2021/02/11/response-to-flatkill-org.html