The flatpak security model, part 3 – The long game

We saw previously that you can open up the Flatpak sandbox in order to run applications that are not built to be sandboxed. However, the long term plan is to make it possible for applications to work sandboxed, and then slowly make this the default for most applications (while losing little or no features). This is a work in progress on many levels, we need work on Flatpak itself, but also on the Linux desktop platform and the applications themselves.

So, how do we reach this long-term goal?

Some things were mentioned in earlier parts. For example, once we have a realistic shot at sandboxing we need to make the permissions more visible in the UI, and make it easier to override them. We also need to drop X11 and move to Wayland, as well as finish the work on PulseAudio permissions.

However, the really important part is being able to have dynamic, fine-grained permissions. This is achieved with something we call Portals.

A Portal is a service that runs on the host, yet is accessible from the sandbox. This is ok because the interface it exposes has been designed in order to be “safe”.

So, what makes a portal safe?

Lets start with a very simple portal, the Network Monitor portal. This service returns network connection status (online/offline) and signals when it changes. You can already get the basic status from the kernel even in the sandbox, but the portal can use Network Manager to get additional information like whether there is a captive portal active, and if the network is metered.

This portal looks at whether the calling app has network access, and if so allows it to read the current status, because this information could already be collected by the app manually (by replicating what network manager does). The portal is merely a more efficient and easy way to do this.

The next example is the Open URI portal. The application sends a request with a URI that it wants to be shown. For instance you could use this for links the user clicked on in the application, but also to show your application documentation.

We don’t want the sandbox to be able to start apps with caller-controlled URIs in the background, because that would be an easy way to do attack them. The way we make this safe is to make the operation interactive and cancellable. So, the portal shows a dialog, allowing the user to select the app to open the URI in, or (if the dialog was unexpected) close the dialog. All this happens outside the sandbox, which means that the user is always in control of what gets launched and when.

A similar example is the FileChooser portal. The sandbox cannot see the users files, but it can request the user to pick a file. Once a file is chosen outside the sandbox, the application is granted access to it (and only it). In this case too it is the interactivity and cancellability that makes the operation safe.

Another form of portal is geolocation. This is safe because the portal can reliably identify the calling application, and it keeps a list of which applications are currently allowed access. If the application is not allowed it replies that it doesn’t know the location. Then a UI can be created in the desktop to allow the user to configure these permissions. For instance, there can be an application list in the control center, or there could be a notification that lets you grant access.

To sum up, portals are considered safe for one of these reasons:

The portal doesn’t expose any info you wouldn’t already know, or which is deemed unsafe

The operation is interactive and cancellable

Portals can reliably identify applications and apply dynamic rules

Theoretically any kind of service designed in this way could be called a portal. For instance, one could call Wayland a UI portal. However, in practice portals are dbus services. In fact by default Flatpak lets the sandbox talk to any service named org.freedesktop.portal.* on the session bus.

The portals mentioned above are part of the Desktop portal, xdg-desktop-portal. It is a UI-less, desktop-independent service. But for all user-interaction or policy it defers to a desktop-specific backend. There are currently backends for Gtk and (work in progress) KDE. For sandboxing to work these need to be installed on the host system.

In addition the the previously listed portals, xdg-desktop-portal also contains:

Printing

User account information

Inhibiting suspend

Notifications

Proxy configuration

Screenshot request

Device access request

There is also a portal shipped with flatpak, the Document portal. It’s permissions based, and is what the FileChooser portal uses to grant access to files dynamincally on a file-by-file basis.

We are also planning to add more portals as needed. For instance we’d like to add a Share portal that lets you easily share content with registered handlers (for instance posting text to a Twitter or Facebook app).

This is all very reminiscent of the PowerBox concept from Plash / CapDesk etc – which is now quite an old concept – good to see it getting reinvented to bring POLA, and hence more security, to the masses. Have you guys seen / been influenced at all by http://zesty.ca/pubs/icics-2002-uidss.pdf

Does that mean that at some point in the future, Flatpak will start forcibly sandboxing existing Flatpak apps? Does that mean those existing apps will stop working?

For example, I assume that the current Flatpak LibreOffice can open arbitrary files from my home folder, because there’s no sandbox stopping it. If in future the safe way to achieve this is via a file-select portal, how can Flatpak know at install time that LibreOffice is going to need to use that file-select portal?

OK, so if I understand rightly, non-sandbox-aware flatpaks will still exist and be able to run without being sandboxed. I think that would be a mistake:

Some third party vendors will inevitably go for the quickest easiest approach to packaging their app. These will be the vendors who aren’t really interested in Linux users, whose software you don’t want to use but have to. (Hello, Atlassian!)

Users will quickly get used to ignoring the big scary “this app will startle your cat, offend your boss and email your browser history to your gran” warning, because their other option is “don’t get your work done” – and we’ll be back to users installing unfettered software from random web pages that they shouldn’t trust but do.

IMO, the endgame should be that all flatpaks must be sandboxed and therefore safe.

I think it’s fair to say that the idea is similar to the concept of Android permissions, which is great. The problem here is that it’s actually the old concept of Android permissions, in which the user has to agree to give the application access to everything it requests upon installations, and their only other option is to not install it at all.
The new concept, however, is about runtime permissions. The application requests access to permissions interactively from the user at runtime, and the user is given the option to either agree or disagree to provide said permission. The major benefit this design brings is allowing the user more control over the behavior of the applications they run, by encouraging developers to provide alternative functionality for dealing with missing permissions. For example, the Facebook application on Android can run very well even when it isn’t provided with any access to the user’s current location. Facebook developers simply had to handle this case by disabling all location-related functionality in the application.