© Ian Allenden

Ein eigentlich verbotener Benutzername zwingt Systemd zu einer unerwarteten Entscheidung. Entwickler gaben sich zunächst uneinsichtig.

Der Systemd-Daemon [1] wird unter Linux als erster Prozess mit der Prozess-ID 1 gestartet. Anschließend ist er dann selber für das Starten, Überwachen und Beenden anderer Prozesse verantwortlich. Dabei kann er solche Dienste statt mit Rootrechten auch mit den reduzierten Rechten eines normalen Anwenders starten. Auf dieses Systemd-Verhalten verlassen sich praktisch alle Linux-Systeme beim Systemstart.

Doch stellte sich nun heraus, dass der Mechanismus nicht immer wie erwartet funktioniert. Wenn zum Beispiel ein Benutzername verwendet wird, der mit einer Ziffer beginnt, wie etwa »0day«. Dann führt Systemd den entsprechenden Dienst mit Rootrechten aus. Einem Systemd-Anwender fiel dies Verhalten auf und er formulierte einen entsprechen Bug-Report [2].

01 [Unit]
02 Description=0day socat service
03 After=network.target
04
05 [Service]
06 User=0day
07 Restart=always
08 Type=simple
09 WorkingDirectory=/home/0day/
10 ExecStart=/usr/bin/socat TCP-LISTEN:18086,reuseaddr,
   fork EXEC:"/opt/run-elf"
11
12 [Install]
13 WantedBy=multi-user.target

Bei seinen Tests verwendete er die Systemd-Konfiguration aus Listing 1 mit dem Benutzer »0day«. Anschließend startete er den Dienst via:

systemctl start socat.service

Verwundert stellte er dann fest, dass dieser Dienst mit Root- statt mit 0day-Rechten lief. Dieses Verhalten war nicht zu erwarten.

Die Systemd-Entwickler reagierten auf diesen Bug-Report mit dem Statement, dass dies kein Systemd-Fehler sei. Ihre Begründung: Unter Linux sind nur solche Benutzernamen zulässig, die mit einem Buchstaben beginnen. Demnach handelt es sich bei »0day« um gar keinen zulässigen Namen.

Systemd sei nun so programmiert, dass es in diesem Fall den Benutzernamen einfach ignoriert und auf das Default-Verhalten zurückfällt. Das heißt, der Dienst startet im Endeffekt mit Rootrechten. Deshalb entschlossen sich die Systemd-Entwickler dazu, den Programmcode nicht zu ändern und den Bugreport zu schließen.

Die Entscheidung ist teilweise nachvollziehbar, da es in der Tat recht schwierig und unwahrscheinlich ist, dass ein Angreifer dieses Systemd-Verhalten gewinnbringend ausnutzen kann. Denn dazu muss zunächst einmal ein entsprechend ungültiger Benutzername auf dem System vorhanden sein. Weiter muss er dann auch in einer Systemd-Konfiguration konkret verwendet werden.

Ein potenzieller Angriff kann nur dann gelingen, wenn ein Systemadministrator schon selbst einen solchen Benutzernamen angelegt und einen Dienst über ihn via Systemd konfiguriert hat. Insgesamt ist dieses Szenario also ziemlich unwahrscheinlich.

Die Linux- und Systemd-Community hat trotzdem recht negativ auf das etwas ignorante Verhalten reagiert. Daraufhin hat der Systemd-Entwickler Zbigniew Jedrzejewski-Szmek einige Tage später ein Patch http://3 vorgeschlagen, das das Default-Verhalten von Systemd modifiziert. Das System lässt sich nun so konfigurieren, dass ein Dienst bei ungültigem Benutzernamen gar nicht mehr startet, sodass etwaige Attacken unmöglich sind.