Sandboxed Applications, the FHS, Distros, and Centralized Decentralization

An overview and brief analysis into the players involved in creating sandboxed application specifications and my preferred route forward

The times, they are a-changin'. We've gone from having container specifications for sandboxing system-wide services like a web server from the underlying system to multiple sandboxed application specifications being explored. The first item of note is which groups are pursuing sandboxed applications.

The first group I'll mention is the systemd folks. They're uniquely situated to pursue sandboxed applications because they have already worked to make the APIs surrounding containerization more accessible and are succeeding at their pursuit of centralization of what it means to be "Linux". As such, they are not only qualified, but they actually have the pull to really make a cross-distro solution actually work out.

The second group is Gnome, whose place in all of this points more towards the higher-level considerations with regards to containerization. They are dealing with user experience first and foremost with the ideas of handling various possible permissions to allow or deny for containerized applications. The big question is how this will affect other desktop environment projects, considering that contention is more likely to occur when dealing with the problem at this higher level. What makes things weird is how Gnome has centralized items like settings (with some programs depending on shared desktop schemas and gtk schemas themselves) and paths hardcoded at compile time, but overridable. To run an application, even with the scheme they've presented, they need to implement some changes lower on their own stack, or include some environment variables when running applications. The latter is a little less clean, but would still do the job.

The first questions I have are about the idea of a "runtime" - what that entails and who will be maintaining it. Solidifying the idea of a runtime is important because it is defines the difference between the system and the application. The UNIX system of today is defined by little more than the filesystem and some running daemons. Those daemons themselves have increased in number, in part due to systemd, though they aren't really central to what it means to have applications running. Even access to devices is largely unimportant for most running applications. Are there libraries that are expected to be present that should be considered part of the operating system rather than part of the application? This is where things quickly get hairy. Even the c library can differ between applications - by the architecture, by the version, and even by which libc we're using. If we cannot first agree on the right libc to use, then the idea of containerized applications falls flat from the get-go because a lot of the point is to enable third parties to produce applications for Linux that they can expect to work. Glibc is obviously the natural choice, but what about the alternatives? Are they of no value beyond embedded applications? I'm certainly exploring that now, but I must at least argue that a libc should be replacable - not just as a reimplementation or fork of another, but rather as an entity following a specification.

Next, we concern ourselves with distributions. The expectation is that a distro is created as more than a set of applications installed together and a wallpaper to go with them. Instead, they embody a philosophy - for better or worse depending on your personal views. Ubuntu, so well known for being "Linux for Human Beings", has become a bastian for inexperienced users while still retaining a good number of experienced users as well. On the other side, Gentoo is known a lot for the high barrier of entry and how much is expected of its users. They are afforded a lot of flexibility, but don't get that much in the way of handholding. If you can't be expected to look something up yourself before asking, then you won't be viewed very positively, and worse, you won't move forward very quickly. The containerization of applications sounds like something that would normally fall under the purview of distros rather than somewhere further upstream. It's the idea of how to construct your system and what it means to maintain it.

The other reason why distros are important in this discussion is asking where they fall in all of this. Runtimes are meant to be distribution-independent, but that only becomes useful if distributions adopt that scheme. In addition, it largely dilutes what it means to be a distro. Applications are to be packaged in a way that no longer really concerns distro maintainers and really decentralizes the whole process of package maintainership. Knowing what the Debian packaging guidelines are like, it would be interesting to see the responses to upstream package quality and whether any real consistency would be enforced.

Finally, we come to the venerable Filesystem Hierarchy Standard, which seems largely outdated because it seems like it wasn't meant to handle such huge amounts of applications and data. The filesystem can hardly be called navigable and the intertwined dependency trees of applications are such that they can only really be understood through the used of external tools - like package managers. Separating out applications from the system greatly reduces the complexity we see and compartmentalizes the complexity of applications. This brings us to my personal views on this and where I'll be taking things with my current distribution project.

I'll be ignoring security - or rather, I won't be improving it. I'll think of that as another step to be done later. I'm not so interested in the containerization of applications becasue I think third party packaging isn't the answer we're really looking for. We want an open-source system, and we want it to play by our rules. Containerization is more helpful for untrusted code and brings us to more of the Android situation where we've got a lot of data, APIs, and grants for application privileges, but people don't think too much about revoking those privileges and it is almost useless that they are shown because you can't stop an application from being able to perform certain actions. You either install it or you don't. Even if we had the capablity to do so, I highly doubt that people would get into the habit of giving applications as limited of a set of privileges as possible. We already fail at that now.

My main goal is to make a UNIX system understandable. The goal of my distribution isn't widespread appeal or production usage, but rather to be a manageable yet powerful learning tool for people to be excited about learning more about their systems and avoid the ever-worsening trap of failing to understand the computerized world around them. To talk about the importance of security while blatantly acting insecurely through your ignorance is shameful. We don't have a test to see whether people should be allowed to use a computer or the internet like we have a driving test. It is considered to be a right of everyone rather than a privilege despite the harm that they can cause. I'm certainly not for the denial of access to information that such tests would cause, but I really wish that people would start taking such an important part of their involvment in the world a bit more seriously and start holding themselves and those around them to higher standards. Free Software is about the ability to exert control over software you're using. People should start to act like it.