Rechte, die nur so weit reichen wie nötig

Härtung wird meist als Frage der Außengrenze verstanden. Der zweite, oft wichtigere Teil beginnt danach: Was kann jemand tun, der einen einzelnen Dienst übernommen hat? Zwischen „ein Webprozess wurde ausgenutzt“ und „die Maschine gehört jemand anderem“ liegt Rechteverwaltung.

Der Bestand: wer darf hier eigentlich was?#

# Konten mit Anmeldemöglichkeit
awk -F: '$3>=1000 && $7!~/(nologin|false)$/ {print $1, $3, $7}' /etc/passwd

# Konten mit UID 0 — es darf genau eines geben
awk -F: '$3==0 {print $1}' /etc/passwd

# Wer darf sudo, und wofür?
getent group sudo admin 2>/dev/null
sudo -l -U benutzername

# Dienste und unter welchem Konto sie laufen
ps -eo user,comm,args --sort=user | grep -v '^root .*\[' | head -30

Die letzte Zeile ist die aufschlussreichste. Alles, was dort als root steht und kein Kernel-Thread ist, gehört einzeln begründet.

Vier Regeln#

1. Ein Konto je Person, keine Sammelkonten. deploy mit drei Schlüsseln in einer Datei beantwortet nach einem Vorfall die Frage „wer war das?“ nicht mehr. Der Aufwand für getrennte Konten ist einmalig, der Nutzen bleibt.

2. root meldet sich nicht an. Das ist bereits Teil von Passwort-Login abschalten:

sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
# erwartet: permitrootlogin no (oder prohibit-password), passwordauthentication no

3. Dienstkonten bekommen keine Shell.

sudo useradd --system --home-dir /nonexistent --shell /usr/sbin/nologin app
sudo chsh -s /usr/sbin/nologin bestehendes-dienstkonto

4. sudo-Regeln sind eng, oder sie sind keine.

# /etc/sudoers.d/deploy — via visudo -f bearbeiten
deploy ALL=(root) NOPASSWD: /bin/systemctl restart app.service, /bin/systemctl status app.service

Die drei Prüfungen, die man selten macht#

# 1. SUID/SGID: Programme, die mit fremden Rechten laufen
sudo find / -xdev \( -perm -4000 -o -perm -2000 \) -type f -printf '%m %u %p\n' 2>/dev/null | sort

# 2. Von allen beschreibbare Dateien und Verzeichnisse ohne Sticky-Bit
sudo find / -xdev -type d -perm -0002 ! -perm -1000 2>/dev/null
sudo find / -xdev -type f -perm -0002 2>/dev/null | head

# 3. Was gehört dem Webkonto, obwohl es das nicht sollte?
sudo find /var/www -user www-data -name '*.php' -newermt '-30 days' | head

Die erste Liste einmal aufheben. Sie ändert sich selten und wenn doch, ist das ein Signal, das auch in Einen Einbruch erkennen auftaucht.

Weiter einsperren#

Rechte sind die eine Hälfte, das Ausmaß der Handlungsfreiheit die andere. Ein Dienst, der als eigener Nutzer läuft, aber trotzdem das ganze Dateisystem sieht und beliebig ins Netz darf, ist nur halb eingegrenzt. Was systemd ohne Zusatzsoftware dagegen anbietet, steht in Dienste einsperren; für Container gilt Container ohne root.

Warum das in kleinen Betrieben besonders zählt#

Auf einer Maschine, die eine einzige Person betreut, wirkt Rechtetrennung wie Verwaltungsaufwand ohne Gegenüber: Es gibt ja niemanden, vor dem man etwas trennen müsste. Der Adressat ist aber nicht die Kollegin, sondern der Prozess. Ein Webserver, ein Bildwandler, ein Cronjob, der eine hochgeladene Datei verarbeitet, jeder von ihnen führt fremde Eingaben aus, und die Rechte, mit denen er das tut, sind die Grenze des Schadens.

Praktisch heißt das drei Dinge, die man einmal einrichtet und danach nie wieder anfasst: Jeder Dienst bekommt ein eigenes Konto ohne Anmeldemöglichkeit. Verzeichnisse, in die eine Anwendung schreibt, gehören ihr und dürfen nichts Ausführbares enthalten, das ausgeliefert wird. Und Aufgaben, die Systemrechte brauchen, laufen über eine eng gefasste sudo-Zeile statt über einen dauerhaft erhöhten Dienst.

Der Prüfpunkt dafür ist unspektakulär und wirksam: Wenn ps -eo user,comm außer Kernel-Threads und einer Handvoll Systemdiensten nichts mehr als root zeigt, ist der wesentliche Teil erledigt. Alles Weitere, Sandbox, Container, Zugriffskontrolle im Kernel, baut darauf auf und ersetzt es nicht.