---
title: Linux service architecture
date: 2021-08-20
tags: [code, linux, security]
description: 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.
---

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](http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html),
the central IPC mechanism that allowed user processes to communicate with
services; [PolicyKit](https://lwn.net/Articles/258592/) (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]

[^1]: Apparently this era was dominated by the fad to call everything "Kit"

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](https://www.youtube.com/watch?v=bIzJyp8sb70)") for all kinds of
things: [accessing files, sending notifications, changing the wallpaper,
…](https://flatpak.github.io/xdg-desktop-portal/portal-docs.html).

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](https://blogs.gnome.org/alexl/2011/09/30/rethinking-the-linux-distibution/)
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](https://lwn.net/Articles/562138/), 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](https://access.redhat.com/security/cve/CVE-2021-3560). 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?