Wenn Sie das Setuid-Bit auf ein Shell-Skript von root setzen, läuft es dann als root?

Eine verbreitete Annahme: chmod u+s script.sh auf einem root-eigenen Skript liefere ein schnelles Hilfsprogramm, das als root läuft. Unter Linux stimmt das nicht, und das prägt auch das Audit auf Rechteausweitung.

Was der Kernel tut

Die Handbuchseite execve(2) besagt, Linux „(wie die meisten anderen modernen UNIX-Systeme) ignoriert die Set-User-ID- und Set-Group-ID-Bits bei Skripten“. Der Kernel startet den in der #!-Zeile genannten Interpreter, und die effektive UID bleibt die des Aufrufers. Ein historischer Grund sind Race Conditions zwischen der Prüfung der Skriptdatei durch den Kernel und dem erneuten Öffnen durch den Interpreter.

Wo das Bit gilt

Das Set-User-ID-Bit wird bei nativen Binaries beachtet. Dieselbe Seite nennt Fälle, in denen es übergangen wird, etwa bei einem mit nosuid eingehängten Dateisystem. Das Verhalten auf solchen Mounts hängt von der Kernelversion ab: Manche verweigern die Ausführung mit EPERM, andere führen die Datei ohne Rechtewechsel aus.

Sicherheitsfolgen

Beim Audit eines Linux-Hosts ist das Aufzählen von SUID-Binaries ergiebig; SUID-Skripte sind es nicht. Brauchen Admins ein privilegiertes Hilfsprogramm, nutzt man einen kleinen kompilierten Wrapper, eine eng gefasste sudo-Regel oder File Capabilities, jeweils mit eigenen Risiken.

Warum die Distraktoren verlocken

„Läuft als root“ ist die intuitive Antwort. „Nur wenn für alle schreibbar“ und „nur Bash“ erfinden nicht existierende Regeln.

Was Interviewer hören wollen

„Linux ignoriert SUID bei Skripten; es wirkt bei kompilierten Binaries; nosuid deaktiviert es ebenfalls“, samt Konsequenz für das Audit.