Ξ

Linux service architecture

Published on 2021-08-20 code linux security

So I have been using linux for about 15 years now. For this whole time I had the feeling that a shift was going on under the surface that no one talked about. Sure, the surface level effects were discussed exhaustively (think d-bus, systemd, flatpak) but few people seemed to realize there was an underlying current that connected all these developments.

Maybe I am totally mistaken and what I want to point out is clear as daylight to everyone but me. But I have never seen it spelled out. So I will attempt to do the spelling.

Chapter 1: Traditional Unix

A process on a unix system traditionally acts as a proxy for the user. If I use some software, that software can do anything that I can do. And if I use some software as root that software is not restricted at all.

There have been attempts at more fine-grained access control with systems such as SELinux or AppArmor, but writing correct configuration for them is tedious. So most processes run unconfined.

Chapter 2: The rise of system services

Running software as root is dangerous, so we want to avoid that. Additionally, especially on single-user systems, it does not make much sense to require root for stuff like connecting to the network, mounting a USB stick, or rebooting. So how can we provide these traditionally root-only actions to non-root users?

Someone came up with the concept of system services that are allowed to do all kinds of stuff, but that listen to the commands of regular users. Of course, on its own this would just be a security bypass. So we needed to add a system for access control back in.

This change happend when I started using linux around 2006 and I remember being confused by all the names:

There was d-bus, the central IPC mechanism that allowed user processes to communicate with services; PolicyKit (later polkit) that handled access control; there was something called HAL that was replaced by DeviceKit which was later split into udisks and upower; NetworkManager was around; and some other services like RealtimeKit or PackageKit.1

With all these new services around, launching them fast and in the right order moved into focus. So in 2010 we got systemd, a powerful new init system that would cause many heated discussion throughout the next years.

In today’s linux there are few reasons to ever use sudo. (At least in theory, because I for one still use mount over udiskctl and apt over pkcon.)

Chapter 3: Same concept, different name

After the threat of software running as root was banned, people quickly realized that running as regular users also comes with risks. A tame-looking application could theoretically steal all of the user’s private photos. So how can we prevent that?

Soon someone realized that the very same mechanisms that already worked for taming root could be used to the same effect on regular users: Provide a service that runs as the user, run the application as less-than-a-user, and allow them to communicate.

D-bus and systemd were already capable of handling user services. Running applications as less-than-a-user became possible thanks to the same low-level sandboxing mechanisms that were also used for container systems like docker.

So people came together and developed user services (now called “portals”) for all kinds of things: accessing files, sending notifications, changing the wallpaper, ….

This coincided with a change in the graphics system. The old system (X11) was replaced by a new one (wayland). In that process some of the functionality that had traditionally been provided by X11 also moved to user services (e.g. screenshots and screen sharing).

Also at the same time there was a push to change the way we package software. The idea was to make it easier for software vendors to bundle their software for linux without relying on distributions. This was supposed to work via application bundles such as flatpak, snap, or AppImage.

Given the huge role distributions have traditionally played in the linux community, this would of course be a major social shift. But it would also be a major shift in the security model because software would no longer be reviewed and vetted by distributions. Instead, users would just download applications from the internet, just like on windows. Running untrusted code feels much less scary when it is sandboxed and applications need stable API to program against, so this whole idea is closely related to that of portals.

Chapter 4: What it all means

I think I have now mentioned every single hot linux topic from the past 15 years at least once. And everything is connected!

I don’t believe there is a conspiracy though. However I believe that looking at these larger developments can help us understand what is going on. Each individual step may sound reasonable. But what about the whole thing?

I am very much not sure. Increasing security sounds good, but I get the feeling that all this has just replaced the traditional (and well understood) unix permission system by the much more complex polkit. The effort of porting the desktop to this new system is huge and still ongoing. I feel grateful to everyone who is contributing to this effort. But at the same time I am not convinced that it is really worth their time.

Systemd has had sandboxing features for quite some time. On my current debian 11 installation, systemd-analyze security reports that 27 of 40 system service are unsafe. Only 4 are OK. Maybe this is because there are 80 (!) different settings that are considered relevant for security.

This tells me that we are not using the security tools we have. We do not use SELinux, we do not use AppArmor, and (so far) we do not use flatpak sandboxing.

I am not an expert by far. But intuitively I would feel safer with a simpler architecture and manual code review by distributions.

What do you think?


  1. Apparently this era was dominated by the fad to call everything “Kit”↩︎