Gnome Applications Sandboxing 2

This post was made with another stylesheet and it might be messed up!

Was about a month ago when Stef Walter proposed in Gnome Whiteboards the user interaction and expectations of sandboxed applications. App Sandboxing is about “properly” isolating Apps from the core system. This is how you can achieve the maximum privacy ..and stability of a system.

Allan Day sets some general goals for Sandboxed Apps, where Alexander Larsson goes a step further with “bundled” Apps. Yeap this is Glick2!

These are some general notes, to a programming problem that affects almost every single software out there. There isn’t really a solution for a perfect sandboxing, but developers -even the Google’ ones- are always seeking to build a better platform for running applications -or even plugins in a micro-App scale.

Goals

Application sandboxing has a range of goals, not all of which are directly related (at least as far as the user experience is concerned):

Maintain the integrity of the system
- Applications should not be able to undermine the system – they should not be able to cause it not to function, or to function in a sub-optimal manner
Ensure that system resources are always available for what the user wants to do
- Background tasks should never stand in the way of user interaction – the focused application should always have the resources to behave in an effective manner
Guarantee conformity in the behaviour of applications
- If you quit an application, it should always quit
- It should always be possible to uninstall an application
Limit the integration points between the application and the system
- Applications should not be able to cook up their own forms of system integration
- Each application should have access to the same set of predictable integration points
The user should have control over application access to data and to particular services. This includes
- Online accounts
- The user’s local files
- System data services, like contacts and calendar
- Location services
Make system-level actions out of reach for applications. eg:
- Force logout
- System shutdown/restart

Source: https://live.gnome.org/Design/Whiteboards/ApplicationSandboxing

Allan just quickly mentions some of the goals that Gnome Platform should provide (specially to 3rd party Apps), so the end user can get the most possible privacy/security in a stable system. The question is how you can achieve all the above. Well, an answer could be by shipping “bundled” Apps.

Glick2

What an bundled App is? An App that ships itself and also all its dependencies in one single package. Sounds nasty, doesn’t it? On the other hand, having 20+ package managers -for every single Linux Distro-, is nastier and as long as developers can’t make their mind towards to a Unified Package system, bundled Apps, could be a solution. One more advantage of bundles, is that guarantee they will interfere with the core system as less as possible and hence make perfect sense for a sandboxed environment.

Alexander Larsson is working to Glick2 and even if is a Gnome project, it isn’t at the moment supported to install Applications (it isn’t done anyway) in Gnome. Here is how it works:

Glick 2 is a working software, but to be honest I didn’t manage to run it :)

Issues with Apps

Every package installs into a single large “system” where everything interacts in unpredictable ways. For example, upgrading a library to fix one app might affect other applications.
Everyone is running a different set of bits:
- The package set for each user is different, and per the above all packages interact which can cause problems
- Package installation modify the system at runtime, including running scripts on the users machine. This can give different results due to different package set, install order, hardware, etc.

Pros with Bundles

Installing applications not packaged for your distribution
Installing a newer version of an application that requires newer dependencies than what is in your current repositories
Keeping multiple versions of the same app installed
Keeping older versions of applications running as you update your overall system

Cons with Bundle

Its a lot of work to create a bundle, as you have to build all the dependencies of your app yourself
Shared libraries used by several apps are not shared, leading to higher memory use and more disk i/o
Its hard for bundles to interact with the system, for instance to expose icons and desktop files to the desktop, or add a new mimetype

Most of the issues with bundled applications (like extra RAM) have a solution.

You can read more into Alexander’s blog: http://blogs.gnome.org/alexl/2011/09/30/rethinking-the-linux-distibution/

Glick2 is available for testing in: http://git.gnome.org/browse/glick2/
How to run it: http://git.gnome.org/browse/glick2/tree/README

Michael

love this idea of sandboxing, it may be a bit more work but could also lead to more portable and easy to manage apps, if its not a system app it should be included in the bundle, for example some programs need 2 different versions of python to run but most people dont want both installed and running on their system unless they need to run the app. The increased disk and memory use is trivial compared to the added security and portability in my opinion :)

Philip Witte

I actually disagree. Sandboxing sounds great for development (dependencies aren’t moving targets) but it’s more efficient, stable, and convenient (to users and developers) to collect dependencies in a universal repository. The problem is no one’s doing it quite right, yet. Arch Linux is there with their software repos, everything’s bleeding edge and very stable. The problem is Arch is super low-level, and they expect their users to keep up. If they switch some core part of the OS (like systemd), then you’ve got to manually adjust some files to bring your system up to speed… that obviously wont work for casual users.

That’s why Manjaro Linux looks so promising to me. They lag behind Arch’s repos about a month on core software and use the time to write and test upgrade scripts (at least I think that’s the idea). So casual users don’t have to worry about it. In theory, once the project is more complete, they’ll provide casual users with a universal access to the latest software (from the kernal to the apps) without upgrade complication. Users wont need to do major updates every six months, but their system and software will constantly stay up-to-date, and they’ll only need to know how to access the Software Center app to find what they need.

Marcio

In my opinion, sandboxed apps are to developer outside opensource projects like gnome, gnu, kde… This is a form to make easy the distribuition of proprietary software like VariCad for example.

Sistem packages have to use the traditional package system. I like the ideia of to have some 3rd-party apps isolate of my base system.

JJ

Thats true. We can eliminiate the deb/rpm splits. But then again how do we update individual applications? Application update with a single click was a great strength of GNU/linux. Also how do we have a centralised repo for applications? I don’t expect distros to move to this bundle system anytime soon.

Michael

I actually think this could be done easily, ios uses a similar style for their apps and its updated through the app store much like it would be through a repo, its all the same stuff just instead of updating things system wide its only for a specific app. Id much rather have stuff centralized to an app, i hate when i have 500 dependencies installed system wide on my machine to try out some obscure program in apt etc.

david

What is the difference with the AppImage project (PortableLinuxApps.org)?

JJ

There is no system integration for Appimage.

Júlio Brito

Great