Ist das Konto „root“ unter Linux wegen seines Namens mächtig?
Kurzantwort
Nein. Der Kernel schaut nicht auf den Kontonamen: Privilegierte Prozesse sind diejenigen mit effektiver Benutzer-ID 0, unprivilegierte haben eine effektive UID ungleich null. Ein zweites Konto mit UID 0 ist daher genauso mächtig wie „root“ — unerwartete UID-0-Einträge sind eine klassische Hintertür. Seit Linux 2.2 ist diese Superuser-Macht außerdem in Capabilities unterteilt, die einzeln vergeben werden können.
Viele antworten aus Gewohnheit: „root ist das Admin-Konto.“ Die Frage prüft, ob Sie wissen, was der Kernel tatsächlich verwendet, um Privilegien zu entscheiden.
Der Kernel prüft die UID, nicht den Namen
Die Capabilities-Manpage beschreibt das klassische UNIX-Modell: Privilegierte Prozesse haben eine effektive Benutzer-ID 0 (Superuser bzw. root), unprivilegierte Prozesse eine effektive UID ungleich null. Der Name root ist nur ein Label in /etc/passwd, das auf diese Zahl abgebildet wird. Fügt man einen zweiten Eintrag mit UID 0 hinzu — etwa toor oder backup — ist auch dieses Konto ein vollwertiger Superuser.
Warum Verteidiger das beachten
Ein Angreifer, der /etc/passwd um ein UID-0-Konto ergänzt, erhält root, ohne das root-Passwort oder die sudo-Konfiguration anzufassen. Die Suche nach jedem UID-0-Eintrag außer root ist deshalb ein grundlegender Persistenz-Check in Härtungs- und Hunting-Checklisten.
Root ist nicht mehr Alles-oder-Nichts
Seit Linux 2.2 sind die traditionell dem Superuser zugeordneten Privilegien in einzelne Einheiten, die Capabilities, aufgeteilt, die unabhängig voneinander aktiviert und deaktiviert werden können. CAP_DAC_OVERRIDE umgeht zum Beispiel die Prüfungen für Lese-, Schreib- und Ausführungsrechte. Ein Dienst kann nur die benötigte Capability erhalten, statt als volles root zu laufen.
Warum die Distraktoren scheitern
- „Wegen des Namens“ und „wegen /root“ sind Volkserklärungen: Der Kernel konsultiert sie nie.
- „Wegen der Shell“ verwechselt das Login-Programm mit dem Berechtigungsmodell; die Shell hat keinen Einfluss auf Privilegien.
Was Interviewer hören wollen
„Das Privileg hängt an der effektiven UID 0, nicht am Namen“ — und danach: zusätzliche UID-0-Konten auditieren und Capabilities dem vollen root vorziehen.
Wahrscheinliche Anschlussfragen
- Wie würden Sie einen Linux-Host auf Konten außer „root“ mit UID 0 prüfen?
- Was sind Capabilities, und wie unterscheidet sich CAP_DAC_OVERRIDE von vollem root?
- Warum kann eine Datei mit Capability sicherer oder unauffälliger sein als ein Setuid-root-Binary?