Back to Blog home

What’s up with Sandboxing?

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.

With the upcoming Sailfish OS 4.3.0, you can also test if your application works with the default profile. You can enable the default profile by adding a file called “50-enable-sandboxing.conf” in /etc/sailjail/config, with the content:

[Default Profile]
Enabled=true

This will turn on sandboxing for all apps – something that will also happen by default from Sailfish OS 4.4.0 onwards. With this, when you start your app, you will see the familiar permissions dialog with the default permissions.

Now if you want you can also test opting out from sandboxing, by adding the following lines to your app desktop file:

[X-Sailjail]
Sandboxing=Disabled

Note that disabling the sandbox will not be allowed in the Jolla Store, but it might be useful in your own apps which you do not plan to share via the Jolla Store.

There is one difference between the default profile and defining an application profile with otherwise identical permissions: with the default profile you will get ~/{.local/share,.config,.cache}/packagename directories mounted inside the sandbox. With an application profile you will get ~/{.local/share,.config,.cache}/OrganizationName/ApplicationName/ directories instead, i.e. using the definitions from your X-Sailjail section.

Conclusion

Application Sandboxing as a concept has been part of Sailfish OS for a while now. It will soon be enabled for all 3rd party apps. When this happens, the only change end users should notice will be the permission dialog when launching an app for the first time. Now is the time for application developers to check that their applications work as expected inside sandboxes.

While all applications in the Jolla Store are expected to work inside sandboxes even without changes, it’s always a good idea to verify that your app works beforehand. And while you’re at it, you might want to consider defining the specific set of permissions which are needed for your app. The default list of permissions is quite long, and for the end user it will always look better if the application only requests those permissions which it actually needs.

Ville Nummela

Technical Product Manager at Jolla. Compensates for gadget addiction by hiking in the wilderness.

 

6 Comments

  1. Avatar

    Thanks for the details, Ville, really great that you keep us informed!

    Would you mind updating the developer documentation at https://sailfishos.org/develop/docs/ accordingly or is this already in the pipeline? I would especially be interested in a list of permissions and what they actually do. In addition some migration tips and tricks for the ~/… directories would really be appreciated as they seem to change once I would like to get my own profile.

    Moreover, will Harbour-compliant apps have access to all possible permissions or will there be restrictions? Especially asking because access to contacts is broken since 4.0.1 as the non-privileged DB is no longer updated since then. I really need a Harbour-compliant way of accessing contacts again as soon as possible… 😉

    • Ville Nummela

      Thanks for the questions!

      Yes, we definitely will keep on updating the documentation.

      Your question about all possible permissions is a bit trickier, as it involves predicting the future. On the other hand, as the permissions are always asked from the end user, I don’t see why we couldn’t add allow all possible permissions. And on the other hand, I can also imagine that we might want to restrict some really permissive permission altogether.

      The specific case of contacts is indeed a bit special. There’s clearly a lot of demand for that. We’ll see what we can do, but I can’t give you any promises about timeline.

  2. Avatar

    Great to see some progress in a sandboxing and permission system. While I appreciate you giving us an overview of your plans, one detail of it concerns me:
    So far your sandboxing plans assign each application a profile of permissions it is requesting and a user either accepts all of these permissions or stops using the app. When looking back to the early Android days when its app permission system was a similar style, it IMHO became obvious that any good permission system needs to provide the possibility of selectively granting the permissions requested instead of a “It’s sink or swim” approach. A user wants to use an application that fulfills their current need, and if such an application requests a large amount of permissions, they will – sometimes grudgingly – accept this large list. Especially when these applications are in a strong negotiation position due to a lack of alternatives.
    Also, permissions for rarely used edge cases or optional features always have to be granted.

    So do you have any plans for making the permissions of an app configurable and selectable?
    While it’d be an easy approach to just modify the application profile through e.g System Settings, some additional requirements are lacking:
    Applications need to be able to deal with certain permissions not being granted, need to fail gracefully or be able to discover the set of permissions granted currently.
    For being able to dynamically grant rarely used optional permissions, apps need an API for indicating the need for a certain permissions, or even for a system dialogue to grant that permission.

    Curious about the user journey on your mind =)

  3. Avatar

    So it will be possible to manage the rights of the native apps and Android applications, for both Android 4.4 and 8.0? Because up to now, we can just withdraw the rights to Android completely and for the Sailfish part we can just read the rights an app is asking for. And will iit also work for SFOS 3.1 Kernel? Or only with the 4.4 Kernel? As the Kernel 4.4 version already seems to offer rights management for Android apps. Thanks in advance for the info! 🙂

  4. Avatar

    Continuing schmittlauch’s thoughts on “sink or swim”.

    My dream phone would allow me to flexibly feed arbitrary data to any data channel of any app.
    An app *requires* phonebook access and claims that it won’t work without it? Fine, let me construct a separate mockup phonebook and redirect all phonebook requests of this app to it.
    An app *requires* camera access? Let me feed some *.jpeg to it any time it tries to take a photo.
    It requires microphone access? Let me feed some noise instead. And so on.

    It would also be great to have some integrated logging system, so I could see what app tried to access what and act accordingly.

  5. Avatar

    OMG! FINALY
    November 2014 is paid Jolla $224 and seven! yes seven years later I finaly got my full refund.

    Took them seven freakin years to pay me. Seven years of false promises and load of bullshit from the Jolla CEO and rest of their management team.

    Thank you Jolla for f*cking up my thrust in crowdfunding!

    b.t.w. you still owe me $29 in interrest you got the past 7 years.

Submit a Comment

We use cookies to improve your user experience and to help us to develop our services. By continuing to browse the site, you approve of our use of cookies.