(https://blog.jolla.com/whats-up-with-sandboxing/) What's up with Sandboxing?
Sep 27th 2021, 14:00
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.
(https://blog.jolla.com/content/uploads/2021/09/Sandboxing-Arch-Diagram.jpg)
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.
(https://blog.jolla.com/content/uploads/2021/09/Sandboxing-Screens-narrow.jpg)
Now if you want you can also test opting out from sandboxing, by adding the following lines to your app desktop file:
[X-Sailjail]
Sandboxed=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.
The post (https://blog.jolla.com/whats-up-with-sandboxing/) What's up with Sandboxing? appeared first on (https://blog.jolla.com) Jolla Blog.
https://blog.jolla.com/whats-up-with-sandboxing/
Toda la información y las últimas novedades relativas al software libre y a Ubuntu las puedes encontrar en (http://linuxleon.org) linuxleon.org y (http://ubuntuleon.com) ubuntuleon.com.
(https://blogtrottr.com/unsubscribe/nx2/dXBH7w) unsubscribe from this feed
0 comentarios:
Publicar un comentario