In February 2021 we released Sailfish OS 4.0.1 Koli, which introduced a new concept into the OS: Application sandboxing. For the device user, the sandboxing is mostly visible in the permissions dialogs,  displayed when a sandboxed app is run for the first time. In this blog post, I’ll dig into the current status, our plans for the future, and what this all means for application developers.

In case you haven’t heard about sandboxing in the context of Sailfish OS before, here’s a short primer: the purpose of sandboxing is to
improve user privacy, by limiting what applications can do. This is done using a security technology in the Linux kernel called namespaces. This is a lightweight but effective mechanism, which lets us define quite nicely which resources each app can use. All in all, the end result is that the device user is in charge of what resources each app can access.

Where are we now?

When we first introduced sandboxing, it was limited to a selection of the Jolla apps. In Sailfish OS 4.2.0 Verla, this has not changed. But things have progressed under the hood, as we are preparing sandboxing to be applied to all 3rd party applications.

Eventually, we are planning to run all apps in a sandbox. If we want to sandbox an app, the app needs to have a set of required permissions, also known as an application profile. Currently, there aren’t any 3rd party apps with defined profiles. Our intention is that when we turn the sandboxing on for all apps, the current existing apps will not be broken. Therefore, we need a default profile, which will be used in case an app hasn’t defined an application profile of its own. The default profile will have broad enough permissions to allow any previously Harbour-allowed app to function.

While the sandboxing has been in use for the Jolla apps, we have noticed that the original set of permissions was not quite granular enough. Since the 4.0.1 release, we have added separate permissions for microphone  and external storage access. Common user directory access (Documents, Downloads, Music, etc.) can now be granted via a single permission. Some quite wide permissions were split into more detailed ones – e.g. the permission to read communication history was split out from the Phone permission. In practice what this means is that developers have better control of their app’s permissions, users can understand better what an app is requesting, and some capabilities which couldn’t be used before will now be available for use by third party apps.

Roadmap

What I’ve written above has mainly touched on the current situation. What I’m a about to write here is a short glimpse of our plan for the near future. As with any plan, it is almost certain that it will change – it is only a matter of how much. So take the next few sections with a grain of salt.

As I already mentioned, we are planning to eventually sandbox all Sailfish apps by default. Currently we are planning to do this in the Sailfish OS 4.4.0 release. What does that mean for application developers? It means that there is plenty of time to test and verify that your app works well in the sandbox. You can start testing already now – and I will demonstrate how you can do that a bit later. Starting from Sailfish OS 4.3.0 those apps which have explicitly defined their own application profile will be sandboxed. And also starting with Sailfish OS 4.3.0, you can test the default profile. However between the 4.3.0 and 4.4.0 releases, apps that don’t define their own profile will run outside the sandbox. We’ve been experimenting with various default permissions for some time now, what we have running internally is already working well. That permission set will be released with the 4.3.0 release, but even at that stage they should still be considered work in progress, as we continue to fine tune the set until the final release in 4.4.0.

Besides preparing for sandboxing of all applications, we are improving application boosting. Boosting refers to improving application launch times by having commonly-used libraries preloaded in memory. In 4.3.0 we will have boosting enabled for some sandboxed applications – camera, browser and email apps will have it enabled by default. Before sandboxing we used to have general purpose booster processes that were used by all applications, but with sandboxing this is no longer possible. The application permissions are defined already when we construct the sandboxes, so in practice this means that for each boosted application we need to have a specific booster process running in the background, resulting in a constant memory overhead even when the application is not running. So it’s a trade off between memory consumption and application startup time. Nevertheless, you can expect to see certain apps start up faster as this is rolled out.

Testing your app

Already with Sailfish OS 4.2.0 you can test application specific sandboxing profiles. If you’re an app developer it’s quite easy: you just need to make some modifications to your desktop file. First of all, you need to add an X-Sailjail section, configure your application name and organization, and add the required permissions there. Something like:

[X-Sailjail]
OrganizationName=your.domain
ApplicationName=YourAppName
Permissions=Audio;Bluetooth;Camera;Internet;Location;MediaIndexing;Microphone

In Sailfish OS 4.2.0, you also need to remove the X-Nemo-Application-Type=sailfish-qt5 definition, and  change the Exec-line to invoke sailjail:

Exec=sailjail -p sandbox-test.desktop /usr/bin/sandbox-test

In Sailfish OS 4.3.0 that change should no longer be necessary. Please note that the Exec line change is not Harbour compatible, so after you have verified that your profile works, you should remove it before uploading your app to Harbour.

Please also note that starting the app directly from the SDK does not invoke Sailjail – you have to start the application from the icon in the app grid.