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).
Lollypop was using external commands to do advanced tasks, so https://github.com/gnumdk/lollypop-portal is a portal for advanced features in Lollypop.
Should help people who wants to port their app to Flatpak.
If you just want to run external commands you can use –talk-name=org.freedesktop.Flatpak which has a service for generic running of external commands.
Obviously completely unsafe in terms of sandboxing, but lets you do interesting things.
First of all: great work! Thx!
You talk about “the long game”. Any estimate/wild guess/… on what time frame we are talking about?
kribati: Its hard to tell, but we’re not all that far. The parts are starting to land. Fedora has wayland by default, some apps are starting to experiment with portals. I’d say 6-12 months maybe?
thx, keep up the good work!
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
Once sandboxing works well enough, will it still be possible for Flatpak apps to run unsandboxed?
If so, how will users know whether a Flatpak app from an untrusted source is safe?
Greg: It will work similar to phones, you’ll see the required permissions when installing.
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?
Greg: No, but you will get some form of page listing of the permissions libreoffice requires, and you have to accept it in order to install.
In the future a sandbox-aware LO flatpak would not request access to all your files.
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.
Greg: Well, the alternative to not allowing weakly sandboxed things is that nobody uses Flatpak, because it gets not traction since you have to modify your app to be sandboxed and nobody else does.
I think in the long term we have to morph the UI from todays very permissive to one that makes an unsafe app stand out a lot over time. Thats the only way this can work.
Great read, and to me, this is the key component to sandboxing. I look forward to following the development of Portals and especially how they’re presented to users.
Very instructive reading, thanks!
What would be interesting would be a comparison with what Canonical is doing with snaps:
https://developer.ubuntu.com/en/snappy/guides/security/
For instance:
– which seccomp filter is more protective? (and how to inspect it?)
– how apparmor compares to bubblewrap ?
– …
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.
Alex: any thoughts on the matter?
I don’t see where you get that idea. That static permissions in flatpak are like old-style android permissions, yes, but the portals are very dynamic.
Ideally everything should be dynamic, but some things (like say granting network access) just has to be done at process setup and can’t be granted later.