SUID, SGID und Sticky Bit verstehen

1. Was besondere Berechtigungsbits wirklich steuern

Die klassischen rwx-Rechte für Owner, Gruppe und Andere reichen für viele alltägliche Szenarien nicht aus. Wie soll ein normaler Benutzer sein eigenes Passwort ändern, wenn dafür ein Schreibzugriff auf die root-geschützte Datei /etc/shadow nötig ist? Wie soll ein Team gemeinsam an einem Projektverzeichnis arbeiten, ohne nach jedem Commit manuell die Gruppenzugehörigkeit neuer Dateien zu korrigieren? Wie verhindert man, dass in einem für alle beschreibbaren Verzeichnis wie /tmp jeder Benutzer fremde Dateien löschen kann? Genau für diese drei Fälle existieren die besonderen Berechtigungsbits SUID, SGID und Sticky Bit.

Technisch sind alle drei Bits Teil desselben 12-Bit-Berechtigungsfeldes einer Inode, das neben den neun Standardbits für rwx noch ein führendes Bit-Triplet trägt. In der Ausgabe von ls -l zeigt sich das als s an der Owner-Execute-Position (SUID), als s an der Group-Execute-Position (SGID) oder als t an der Other-Execute-Position (Sticky Bit). Oktal wird das als vierte, führende Ziffer notiert: 4 für SUID, 2 für SGID, 1 für Sticky Bit, kombinierbar durch Addition. chmod 4755 datei setzt also SUID zusätzlich zu rwxr-xr-x. Die drei Mechanismen sind unabhängig voneinander und wirken je nach Dateityp unterschiedlich, weshalb man sie nie pauschal als eine Einheit behandeln sollte.

2. SUID im Detail: Run-as-Owner

Setzt man das SUID-Bit auf eine ausführbare Datei, ändert der Kernel beim Aufruf von execve() die effektive UID (EUID) des entstehenden Prozesses auf den Eigentümer der Datei, statt auf die reale UID des aufrufenden Benutzers. Alle nachfolgenden Berechtigungsprüfungen im Kernel, etwa beim Oeffnen von Dateien, orientieren sich an der effektiven, nicht an der realen UID. Das klassische Beispiel ist /usr/bin/passwd, das root gehört und SUID gesetzt hat: Ein normaler Benutzer startet passwd mit seiner eigenen UID, der Prozess läuft aber intern mit root-Rechten und darf deshalb den eigenen Eintrag in /etc/shadow aktualisieren, ohne dass die Datei für alle Benutzer beschreibbar sein muss.

Wichtig sind zwei Einschränkungen. Erstens hat SUID auf Verzeichnissen keinerlei Wirkung, es entfaltet sich ausschließlich bei ausführbaren Dateien. Zweitens ignoriert der Linux-Kernel das SUID-Bit bei interpretierten Skripten mit Shebang-Zeile aus historischen Sicherheitsgründen: Eine klassische Race Condition zwischen dem Oeffnen der Skriptdatei und dem Start des Interpreters ließ sich früher für Angriffe ausnutzen, weshalb moderne Kernel #!/bin/bash-Skripte beim Setzen von SUID schlicht ohne erhöhte Rechte ausführen. SUID funktioniert also verlässlich nur bei kompilierten ELF-Binaries.

3. SGID im Detail: Run-as-Group und Verzeichnisvererbung

Das SGID-Bit auf einer ausführbaren Datei funktioniert analog zu SUID, nur bezogen auf die Gruppe: Der Kernel setzt die effektive GID (EGID) des Prozesses auf die Gruppe der Datei statt auf die primäre Gruppe des aufrufenden Benutzers. Ein Beispiel ist wall, das über die Gruppe tty Schreibzugriff auf fremde Terminal-Geräte erhält, ohne dass jeder Benutzer direkt Mitglied dieser Gruppe sein muss.

Deutlich häufiger genutzt wird SGID jedoch auf Verzeichnissen, wo es ein völlig anderes Verhalten zeigt als auf Dateien: Neue Dateien und Unterverzeichnisse, die innerhalb eines SGID-Verzeichnisses angelegt werden, erben automatisch dessen Gruppenzugehörigkeit statt der primären Gruppe des Erstellers. Zusätzlich vererben neu angelegte Unterverzeichnisse das SGID-Bit selbst weiter, sodass die Gruppenvererbung rekursiv über die gesamte Verzeichnisstruktur erhalten bleibt. Das macht SGID zum zentralen Werkzeug für gemeinsam genutzte Arbeitsverzeichnisse mehrerer Benutzer.

4. Sticky Bit: Löschschutz in gemeinsamen Verzeichnissen

Historisch bewirkte das Sticky Bit auf ausführbaren Dateien, dass deren Programmtext nach Beendigung im Swap-Bereich verblieb, um erneute Aufrufe zu beschleunigen. Dieses Verhalten ist auf modernen Linux-Systemen bedeutungslos, der Kernel ignoriert das Sticky Bit auf Dateien vollständig. Relevant ist es heute ausschließlich auf Verzeichnissen: Ist es gesetzt, darf eine Datei innerhalb des Verzeichnisses nur noch vom Dateieigentümer, vom Verzeichniseigentümer oder von root gelöscht, umbenannt oder verschoben werden, selbst wenn das Verzeichnis selbst für alle Benutzer beschreibbar ist.

Das bekannteste Beispiel ist /tmp mit dem Modus drwxrwxrwt, oktal 1777. Jeder Benutzer darf dort eigene temporäre Dateien anlegen, aber niemand kann die temporären Dateien eines anderen Benutzers löschen oder überschreiben, nur weil das Verzeichnis global beschreibbar ist. Ohne das Sticky Bit wäre /tmp ein triviales Ziel für Denial-of-Service-Angriffe durch das Löschen fremder Lock- und Socket-Dateien. Auch systemd-tmpfiles erzwingt diesen Modus bei jedem Boot über Konfigurationsdateien unter /usr/lib/tmpfiles.d/, damit manuelle Fehlkonfigurationen automatisch korrigiert werden.

5. Bits setzen: chmod symbolisch und oktal

Alle drei Bits lassen sich sowohl symbolisch als auch oktal setzen. Symbolisch verwendet man chmod u+s für SUID, chmod g+s für SGID und chmod +t für das Sticky Bit, jeweils kombinierbar mit den normalen rwx-Operationen. Oktal wird die vierte, führende Ziffer verwendet: 4 steht für SUID, 2 für SGID, 1 für Sticky Bit. Die Werte lassen sich addieren, sodass chmod 6755 gleichzeitig SUID und SGID auf einer Datei mit rwxr-xr-x setzt.

Zum Setzen ist entweder root-Rechte oder Eigentümerschaft der Datei erforderlich, wobei viele Systeme das SUID-Bit beim chown auf einen anderen Eigentümer aus Sicherheitsgründen automatisch entfernen. Ein großes S beziehungsweise T statt kleinem s oder t in der ls -l-Ausgabe signalisiert einen inkonsistenten Zustand: Das Sonderbit ist gesetzt, aber das zugehörige Execute-Bit fehlt, was bei SUID-Dateien meist ein Konfigurationsfehler ist, da ein nicht ausführbares SUID-Binary wirkungslos bleibt.

#!/usr/bin/env bash
# Special permission bits: symbolic and octal notation

# SUID symbolically, on a compiled binary owned by root
sudo chmod u+s /usr/local/bin/backup-agent
ls -l /usr/local/bin/backup-agent
# -rwsr-xr-x 1 root root 48200 Jul 12 09:00 /usr/local/bin/backup-agent

# SUID + SGID + rwxr-xr-x in one octal command
sudo chmod 6755 /usr/local/bin/backup-agent

# SGID on a shared team directory (not a file!)
sudo mkdir -p /srv/www/project
sudo chown root:developers /srv/www/project
sudo chmod 2775 /srv/www/project
ls -ld /srv/www/project
# drwxrwsr-x 2 root developers 4096 Jul 12 09:01 /srv/www/project

# Sticky bit on a shared upload directory
sudo mkdir -p /srv/uploads
sudo chmod 1777 /srv/uploads
ls -ld /srv/uploads
# drwxrwxrwt 2 root root 4096 Jul 12 09:02 /srv/uploads

# Remove a bit again
sudo chmod u-s /usr/local/bin/backup-agent

6. Legitime Einsatzzwecke: passwd, /tmp und Teamverzeichnisse

Neben passwd nutzen klassisch auch mount, su und historisch ping SUID root, weil sie entweder geschützte Konfigurationsdateien schreiben oder Raw Sockets öffnen müssen, was ohne erhöhte Rechte nicht möglich ist. Moderne Distributionen ersetzen SUID root bei ping zunehmend durch Linux Capabilities: setcap cap_net_raw+ep /bin/ping vergibt genau das eine benötigte Recht, ohne dem Programm vollen root-Zugriff zu geben. Das reduziert die Angriffsfläche erheblich, da ein Fehler in ping nicht automatisch zu vollständiger Systemübernahme führt. Bei passwd ist ein vergleichbarer Ersatz kaum möglich, da das Programm generisch auf /etc/shadow schreiben muss.

Für Teamverzeichnisse ist die Kombination aus SGID und einer dedizierten Unix-Gruppe der Standardansatz: Ein Verzeichnis wie /srv/www/project gehört der Gruppe developers und trägt SGID, sodass jede neue Datei automatisch der richtigen Gruppe zugeordnet wird, unabhängig davon, welcher Entwickler sie erstellt hat. Ergänzt man das mit Default-ACLs über setfacl -d -m g:developers:rwx /srv/www/project, lassen sich sogar granulare rwx-Rechte für neue Dateien vorgeben, was über die reine Gruppenvererbung von SGID hinausgeht.

#!/usr/bin/env bash
# Replace SUID-root with a narrow capability where possible
sudo setcap cap_net_raw+ep /bin/ping
getcap /bin/ping
# /bin/ping cap_net_raw=ep

# Verify ping no longer needs SUID at all
ls -l /bin/ping
# -rwxr-xr-x 1 root root 71000 Jul 12 09:05 /bin/ping

# Shared team directory with SGID and a default ACL
sudo groupadd -f developers
sudo mkdir -p /srv/www/project
sudo chgrp developers /srv/www/project
sudo chmod 2775 /srv/www/project
sudo setfacl -d -m g:developers:rwx /srv/www/project

# Any file created here belongs to "developers" automatically
sudo -u alice touch /srv/www/project/index.php
stat -c '%U:%G %A' /srv/www/project/index.php
# alice:developers -rw-rw-r--

7. SUID als Angriffsvektor: Privilege Escalation

Ein SUID-root-Binary, das mehr kann als seine eigentliche Aufgabe erfordert, ist ein klassisches Ziel für Privilege Escalation. Der typische Angriffsablauf: Ein Angreifer erlangt eine Low-Privilege-Shell, etwa über eine verwundbare Webanwendung, und sucht anschließend systematisch nach SUID-root-Binaries, die sich zweckentfremden lassen. Das Projekt GTFOBins katalogisiert genau solche Fälle: Zahlreiche Standardwerkzeuge wie find, vim, nmap oder less besitzen eingebaute Funktionen, um eine Subshell zu starten, und diese Subshell erbt bei gesetztem SUID-Bit automatisch die effektive UID des Dateieigentümers.

Ein reales Beispiel: Setzt ein Administrator versehentlich chmod u+s /usr/bin/find, reicht der Befehl find . -exec /bin/sh -p \; -quit, um eine root-Shell zu erhalten, weil find seinen -exec-Kindprozess mit der eigenen effektiven UID startet. Aehnliche Muster existieren für Umgebungsvariablen-Angriffe wie LD_PRELOAD, bei denen ein Angreifer eine eigene Shared Library in ein SUID-Binary einschleust, sowie für Symlink-Angriffe gegen Programme, die Pfade unsicher verarbeiten. Die Konsequenz für den Betrieb: Universalwerkzeuge sollten niemals SUID root tragen, granularere Mechanismen wie sudo mit eng begrenzten Befehlslisten oder Capabilities sind fast immer die sicherere Wahl.

#!/usr/bin/env bash
# Demonstrating why an unnecessary SUID bit is dangerous
# (run only in an isolated lab environment, never in production)

# Misconfiguration: administrator sets SUID root on a general tool
sudo chmod u+s /usr/bin/find
ls -l /usr/bin/find
# -rwsr-xr-x 1 root root 316280 Jul 12 09:10 /usr/bin/find

# Attacker with a low-privilege shell escalates instantly
find . -exec /bin/sh -p \; -quit
# id
# uid=1000(attacker) euid=0(root) gid=1000(attacker) groups=1000(attacker)

# The fix: remove SUID from general-purpose tools immediately
sudo chmod u-s /usr/bin/find

8. SUID-Binaries auditieren und überwachen

Der erste Schritt jedes Audits ist eine vollständige Bestandsaufnahme: find / -xdev \( -perm -4000 -o -perm -2000 \) -type f -exec ls -la {} \; 2>/dev/null listet alle Dateien mit gesetztem SUID- oder SGID-Bit auf dem aktuellen Dateisystem. Die Option -xdev verhindert, dass gemountete Netzwerkfreigaben oder externe Datenträger unnötig durchsucht werden. Direkt nach einer Neuinstallation oder Härtung sollte diese Liste als Baseline gespeichert werden, etwa als Hash mit sha256sum, um später Abweichungen zuverlässig zu erkennen.

Für laufende Ueberwachung eignet sich auditd: Eine Regel wie auditctl -w /usr -p wa -k suid_watch protokolliert jeden Schreib- oder Attributzugriff unterhalb von /usr im Audit-Log, sodass ein nachträglich gesetztes SUID-Bit sofort mit Zeitstempel und ausführendem Benutzer sichtbar wird. Paketverwaltungen bieten zusätzlich eine schnelle Vergleichsmöglichkeit gegen die erwarteten Werte aus dem Paket: debsums -c unter Debian/Ubuntu beziehungsweise rpm -Va unter RHEL-basierten Systemen markieren Dateien, deren Modus vom Paket-Original abweicht. Werkzeuge wie AIDE gehen noch weiter und überwachen Berechtigungsänderungen als Teil einer vollständigen Dateisystem-Integritätsprüfung mit täglichem Bericht.

{
  "scan_id": "suid-audit-2026-07-12T06-00-00Z",
  "host": "web-prod-03",
  "baseline_file": "/var/lib/suid-audit/baseline.sha256",
  "findings": [
    {
      "path": "/usr/bin/passwd",
      "mode": "4755",
      "owner": "root",
      "group": "root",
      "in_baseline": true,
      "status": "expected"
    },
    {
      "path": "/usr/bin/find",
      "mode": "4755",
      "owner": "root",
      "group": "root",
      "in_baseline": false,
      "status": "new_suid_detected",
      "severity": "critical"
    }
  ],
  "summary": { "total_suid": 24, "total_sgid": 9, "new_since_baseline": 1 }
}

9. Best Practices und Systemhärtung im Vergleich

Neben der reinen Suche nach vorhandenen SUID-Binaries gehört die präventive Härtung zur Standardaufgabe: Dateisysteme, auf denen normale Benutzer schreiben dürfen, sollten grundsätzlich mit der Mount-Option nosuid eingehängt werden, etwa /home, /tmp und /var/tmp in /etc/fstab. Der Kernel ignoriert dann das SUID-Bit auf diesen Dateisystemen komplett, selbst wenn ein Angreifer eine SUID-Datei dorthin hochladen kann. Diese Verteidigungslinie greift zusätzlich zur eigentlichen Ursachenbekämpfung und macht viele Exploit-Ketten von vornherein wirkungslos.

Automatisierung über Configuration-Management stellt sicher, dass Härtungsregeln nicht nur einmalig, sondern kontinuierlich auf einer ganzen Serverflotte durchgesetzt werden. Ein Ansible-Task kann regelmäßig prüfen, ob neue, nicht genehmigte SUID-Dateien aufgetaucht sind, und bei Abweichung automatisch alarmieren oder das Bit sogar direkt entfernen.

# Ansible task: audit SUID/SGID binaries against an approved allowlist
- name: Find all SUID and SGID files on the host
  ansible.builtin.shell: >
    find / -xdev \( -perm -4000 -o -perm -2000 \) -type f 2>/dev/null
  register: suid_scan
  changed_when: false

- name: Compare findings against the approved allowlist
  ansible.builtin.set_fact:
    unexpected_suid: "{{ suid_scan.stdout_lines | difference(approved_suid_allowlist) }}"

- name: Fail the play if unapproved SUID binaries are found
  ansible.builtin.fail:
    msg: "Unapproved SUID/SGID binaries detected: {{ unexpected_suid }}"
  when: unexpected_suid | length > 0

- name: Mount user-writable filesystems with nosuid
  ansible.posix.mount:
    path: "{{ item }}"
    opts: "defaults,nosuid,nodev"
    state: mounted
  loop:
    - /tmp
    - /var/tmp
    - /home

Die Tabelle zeigt ein wiederkehrendes Muster: In fast jedem Fall existiert ein präziserer Mechanismus als das grobe Setzen eines Sonderbits auf ein vollständig freigegebenes Ziel. Wer diese Empfehlungen konsequent umsetzt und zusätzlich nosuid auf allen benutzerschreibbaren Dateisystemen erzwingt, reduziert die Angriffsfläche deutlich, ohne legitime Anwendungsfälle wie passwd oder Teamverzeichnisse einzuschränken.

10. Zusammenfassung

SUID, SGID und Sticky Bit lösen drei unterschiedliche, aber verwandte Probleme im Linux-Rechtemodell. SUID erlaubt einem Programm, mit den Rechten seines Eigentümers statt des aufrufenden Benutzers zu laufen, unverzichtbar für Werkzeuge wie passwd. SGID übernimmt dieselbe Idee für Gruppen und entfaltet auf Verzeichnissen eine zusätzliche, besonders praktische Funktion: die automatische Vererbung der Gruppenzugehörigkeit an neue Dateien. Das Sticky Bit schützt in gemeinsam beschreibbaren Verzeichnissen wie /tmp davor, dass Benutzer gegenseitig ihre Dateien löschen können.

Gleichzeitig sind vor allem SUID-root-Binaries ein bevorzugtes Ziel für Privilege Escalation, wenn sie mehr Funktionalität mitbringen, als für ihren eigentlichen Zweck nötig ist. Ein regelmäßiger Abgleich mit einer Baseline, Ueberwachung über auditd, die konsequente Nutzung von Linux Capabilities statt vollem SUID root und nosuid-Mounts auf benutzerschreibbaren Dateisystemen bilden zusammen eine robuste Verteidigungslinie, ohne die legitimen Einsatzzwecke der Bits einzuschränken.

11. FAQ: SUID, SGID und Sticky Bit