Application sandboxing is a subject that I am passionate about. In recent months I have been involved in a design initiative to plan out how sandboxed applications would work on GNOME, and I gave a talk on this subject at GNOME.Asia early this year, and I’ve been meaning to blog about it ever since.
There’s quite a lot to be said about sandboxed applications, so this is the first of two posts on the subject. In this post, I want to talk about why application sandboxing is important, and it importance across a range of areas. The second post will deal with the actual user experience of using a sandboxed application.
A brief definition
Application sandboxing can mean a number of things. I’m using a fairly loose, abstract, definition, and I don’t want to get too bogged down in technical details. For the purposes of this post, a sandboxed application is an app that:
- Only has access to a limited set of system API.
- Has managed access to additional system API and to user data – so that the application must ask permission for access.
- Can be effectively tracked and managed by the host operating system as it runs.
- Can be installed and updated independently of the host operating system – new dependencies are not required, and the operating system components do not need to be updated.
- Can include any dependencies that are not provided by the operating system.
There are two related aspects to this definition: the first is application distribution, installation and update. The second is a privacy and security framework. Sandboxed applications are containerised, and those containers can include bundled libraries. They have only limited access to the underlying system, and they must ask for user permission to use certain hardware devices (like cameras, microphones or GPS), or to access user data.
Why sandboxing matters
I genuinely think that application sandboxing represents the future for the GNOME project. We have never had a rigourous definition of what an application actually is in the GNOME world. That has led to all kinds of negative consequences, both in terms of the user experience that we provide, and the ability for developers to distribute applications. Conversely, sandboxing infrastructure for GNOME promises to have all kinds of positive consequences.
The following are what I consider to be the most important consequences of application sandboxing.
Security and privacy, I think, are core beliefs for Free Software. Users should be able to trust us to have their interests at heart, and should be able to have more faith in our products than proprietary alternatives. Ironically, though, the Free Software desktop world hasn’t done a great job at security. It is actually pretty scary what a malicious desktop application could do if it wants to. We rely on transparency and good faith to ensure that applications do not infringe on user privacy, rather than robust technical architecture.
If we want to be able to make a strong case for the value of Free Software desktops, we need to be able to make serious claims about the robustness of our security and privacy features. It is time to stand up for what we believe in, and to make our technologies reflect our beliefs and commitments. Otherwise, it is quite difficult for us to tell a coherent story about why we or our products matter.
Application developer experience
Sandboxed applications are an essential part of an effective, easy-to-use application development platform. By definition, a sandboxed application has access to less API than one that isn’t sandboxed. This is actually a good thing – it makes it clear to application developers which API is supported by the platform. It gives them less to deal with, and reduces uncertainty about how they should implement their application.
It is also easier for us to develop our application development platform if it works through sandboxing – since we will have a clearer, more tightly defined set of platform functionality to worry about. Sandboxing makes it easier to look at the platform as a whole and identify missing functionality, or functionality that can be improved.
This is an important issue for application developers, as well as the GNOME application ecosystem. Right now it is far too difficult for developers to get their applications into the hands of users. Application distribution is fragmented, slow, and fraught with organisational hurdles.
An application development platform built on sandboxing and containerisation will provide a stable base which application authors can target. This will allow application authors to target specific versions of the platform, to easily distribute and update their applications, and to have greater confidence in how their application will look and perform in the hands of users. It will make it easier for developers to independently distribute their applications, should they want to.
The primary purpose of any operating system is to host applications. While there are certain additional features that these operating systems need to provide, wherever possible, the base operating system should be as minimal as possible, and only provide functionality that is needed by the applications it hosts.
Right now, we don’t have a clearly defined set of API that is exposed to applications. As a result, it becomes rather difficult to decide which functionality a desktop operating system should provide and, without a clearly defined application platform, we lack the ability to rigorously define what functionality and components the host operating system should include.
Application sandboxing helps with this problem of operating system definition. The API that is exposed to applications becomes the primary reference point for determining which components should make up the operating system. Addressing this issue of OS definition has a number of other beneficial consequences: once you can clearly define an operating system, testing becomes a lot easier. Writing documentation gets easier. Providing support gets easier.
OS user experience
Application sandboxing and containerisation enables a far superior user experience. I’ve already alluded to some of the ways that it does this – protecting privacy is a user experience issue, for example. Likewise, application installation and update also have user experience consequences.
There are other ways that sandboxing helps to improve user experience though. It ensures that applications behave consistently, as well as preventing them from misbehaving. It also enables the operating system to effectively manage system resources. Applications that are running in the background can be throttled to ensure that the system and whatever you are interacting with remains fast and responsive. Power management can be improved. Network bandwidth can be portioned out more effectively.
Enabling the operating system to effectively manage applications is a key way that we can make the user experience consistent, smooth, and predictable. It is 2014. Your system should not be laggy and slow because some application is chewing up all your CPU.
Sounds rather good, doesn’t it?
Application definition, integration and management is a fundamental aspect of defining an operating system, a user experience, and an application development platform. As a result, application sandboxing promises to have positive effects across a wide range of areas. I hope that this post has illustrated where application sandboxing will have a positive impact, and why it is so important.
In the GNOME project, we have been discussing and planning how sandboxed applications could work for some time. Several major technical initiatives – like Wayland and KDBus – are now reaching a stage where they can provide the necessary infrastracture for us to make them a reality. As Christian has posted today, concrete plans now exist for the next stage of development.
In my next post on this subject, I will describe the user experience design that Jon, Jakub and me have been working on in this area. This should give a better idea of what it will be like to use a sandboxed application. It should also give an idea of the outstanding work necessary to make them a reality.
3 thoughts on “Sandboxed applications for GNOME”
Getting a solid and narrow API story is going to help immensely.
I look forward to the day where I can grab a tool from GNOME project that I can run and validate that a particular target OS from any vendor..whether it be virtualized,containerized, or a bare metal install… provides a particular versioned, GNOME application API…or not.
Creating a really usable interface for creating SELinux sandbox configurations and a repository of pre-made ones seems quite achievable.
Run “man sandbox” to get a sense of the parameters to twiddle. (The behaviour of -l seems insane!)
IMO the thing to watch out for though is not to “invent yet another security policy format”… Although you will define things in terms of usability because you are a user-facing GUI, you need to implement the policy by integrating with a real *existing* security framework.
That is – pick and use from the list of SELinux, AppArmor, Docker, chroot, anonymous user accounts. Don’t try to invent something new as you’ll have a very hard time getting traction.
Dan Walsh’s “sandbox -X ” is a good place to start (albeit it’s a little too restricted at the moment). http://danwalsh.livejournal.com/31146.html
Comments are closed.