flatpak: Software should tell me when the application requires sandbox escaping features
@chergert
Submitted by Christian Hergert Assigned to Richard Hughes @hughsie
Link to original bug (#781303)
Description
There are various ways for a flatpak application to escape the sandbox. We should be honest with the user when we know the applications can do this, and when we don't know, but it may be possible the application can do this.
Consider Builder, it has access to the HostCommand API of flatpak's developer DBus service. This means I can run a command on the host and escape the sandbox. We use it for all sorts of stuff. This is the case where we know the application escapes the sandbox. Developer tools will like use this a lot.
Then there is the case were we don't know that it's possible, but we don't know otherwise either. There may be other D-Bus services on the host that meaningfully give you the same access as the developer HostCommand API. So in some sense, if there is a talk-name that is not in some set of pre-known whitelist, we essentially need to let the user know that it's not "fully" sandboxed (for whatever that means).
I'm not going to make a suggestion on conveying this information to the user, as I think the design team can make better suggestions, but I do think it boils down to three levels.
- Trusted (Sandboxed, Wayland, no talking to host DBus services)
- Partially Trusted (Sandboxed, Wayland, talks to N host D-Bus services)
- Unconstrained (Sandboxed, Wayland, but can meaningfully escape the sandbox when necessary, and is therefore inherently more risky).