Best Practices für die Sicherung von Linux-Dateisystemen mit speziellen Berechtigungen

Spezielle Berechtigungen gehören zu den Linux-Funktionen, die in ls -l klein aussehen und in der Produktion eine große Rolle spielen. Ein zusätzliches s bei einer Binärdatei im Besitz von root kann normalen Benutzern ermöglichen, eine eng umrissene privilegierte Aufgabe auszuführen. Ein fehlendes t in einem gemeinsamen Upload-Verzeichnis kann dazu führen, dass Benutzer die Dateien anderer löschen können. Ein SGID-Bit in einem Projektverzeichnis kann Sie vor einem stetigen Strom von Problemen mit der Gruppenbesitzerverwaltung bewahren.

Das Ziel ist nicht, spezielle Bits überall zu verteilen. Das Ziel ist zu wissen, wann SUID, SGID und das Sticky Bit ein echtes Zugriffsproblem lösen und wann sie einen Privilegienpfad schaffen, den Sie später bereuen werden.

Grundlegendes zu Standardberechtigungen – eine Wiederholung

Bevor wir uns mit speziellen Berechtigungen befassen, ist es wichtig, sich an die standardmäßige Triplet-Notation (rwx für Besitzer, Gruppe und Andere) zu erinnern. Diese Berechtigungen werden numerisch mit oktalen Werten dargestellt (z. B. 755 oder 644).

r (Lesen) = 4
w (Schreiben) = 2
x (Ausführen) = 1

Spezielle Berechtigungen modifizieren dieses Basisverhalten und werden durch eine vierte, führende oktale Ziffer (4, 2 oder 1) dargestellt.

Die speziellen Berechtigungen: SUID, SGID und das Sticky Bit

Spezielle Berechtigungen erweitern die Funktionalität über die standardmäßige Zugriffskontrolle hinaus. Sie werden in der langen Auflistung (ls -l) normalerweise durch ein s oder t angezeigt, das das standardmäßige x-Flag ersetzt.

Berechtigung	Oktaler Wert	Effekt
SUID (Set User ID)	4	Die Datei wird mit den Berechtigungen des Dateibesitzers ausgeführt (nicht des Benutzers, der sie ausführt).
SGID (Set Group ID)	2	Die Datei wird mit den Berechtigungen der Dateigruppe ausgeführt, oder neue Dateien erben die Gruppen-ID des übergeordneten Verzeichnisses.
Sticky Bit	1	Verhindert, dass Benutzer Dateien löschen oder umbenennen, die anderen Benutzern in einem gemeinsamen Verzeichnis gehören, selbst wenn sie Schreibberechtigung für das Verzeichnis haben.

1. Set User ID (SUID)

Das SUID-Bit ist mächtig und potenziell gefährlich, wenn es falsch eingesetzt wird. Wenn es für eine ausführbare Datei gesetzt ist, führt jeder Benutzer, der diese Datei ausführt, den Prozess mit den Berechtigungen des Besitzers aus.

Praktischer Anwendungsfall: Dienstprogramme, die Root-Rechte benötigen, um eine bestimmte Aufgabe auszuführen, dem Benutzer aber keinen allgemeinen Root-Zugriff gewähren sollen.

Beispiel: SUID auf `/usr/bin/passwd`

Der Befehl /usr/bin/passwd benötigt normalerweise Root-Zugriff, um die sichere Datei /etc/shadow zu ändern. Er hat das SUID-Bit gesetzt, sodass ein normaler Benutzer vorübergehend die Privilegien des Besitzers (root) nur für die Dauer der Ausführung von passwd erhält, um sein eigenes Passwort zu ändern.

SUID anzeigen: Beachten Sie das s im Ausführungsslot des Besitzers:

ls -l /usr/bin/passwd
# Beispielausgabe: -rwsr-xr-x 1 root root ... /usr/bin/passwd

SUID setzen: Verwenden Sie den oktalen Wert 4 in Kombination mit den Standardberechtigungen (z. B. wird aus 755 4755):

# Angenommen, 'my_script' gehört 'appuser'
chmod 4755 /path/to/my_script

Sicherheitswarnung für SUID: Setzen Sie das SUID-Bit niemals auf allgemeine Shells (wie /bin/bash) oder umfangreiche Wartungsskripte, die externe Eingaben interpretieren. Wenn ein Skript Privilegien benötigt, ist eine enge sudoers-Regel, ein kleiner geprüfter Helfer oder eine Service-API normalerweise sicherer.

Wenn Sie einen Host prüfen, verdienen SUID-Dateien Aufmerksamkeit, da sie bewusste Privilegienübergänge darstellen:

sudo find / -xdev -type f -perm -4000 -ls 2>/dev/null

-xdev hält die Suche auf dem aktuellen Dateisystem, was nützlich ist, wenn /proc, eingehängte Backups oder Netzwerkdateisysteme das Ergebnis verrauschen würden. Scannen Sie auf Servern mit separaten Mounts jedes reale Dateisystem gezielt.

2. Set Group ID (SGID)

Das SGID-Bit hat zwei Hauptfunktionen, je nachdem, ob es auf eine Datei oder ein Verzeichnis angewendet wird.

A. SGID auf ausführbaren Dateien

Wenn es für eine ausführbare Datei gesetzt ist, läuft der Prozess mit den Berechtigungen, die mit dem Gruppenbesitz der Datei verbunden sind, nicht mit der primären Gruppe des Benutzers.

B. SGID auf Verzeichnissen (Entscheidend für gemeinsame Umgebungen)

Wenn es für ein Verzeichnis gesetzt ist, erbt jede neue Datei oder jedes neue Unterverzeichnis, das darin erstellt wird, automatisch den Gruppenbesitz des übergeordneten Verzeichnisses, anstatt der primären Gruppe des Benutzers, der die neue Datei erstellt hat.

Praktischer Anwendungsfall: Gemeinsame Projektordner, in denen alle Mitwirkenden für die Zusammenarbeit einen einheitlichen Gruppen Zugriff haben müssen.

SGID auf einem Verzeichnis setzen: Verwenden Sie den oktalen Wert 2 in Kombination mit den Standardberechtigungen (z. B. wird aus 775 2775):

# Gruppenbesitz auf 'developers' setzen und SGID aktivieren
chgrp developers /srv/shared_project
chmod 2775 /srv/shared_project

Das kümmert sich um die Gruppenvererbung, garantiert aber nicht, dass jede neue Datei gruppenschreibbar ist. Die umask eines Benutzers spielt immer noch eine Rolle. Wenn Mitwirkende Dateien mit einer restriktiven umask wie 077 erstellen, erben die Dateien möglicherweise die Gruppe developers, sind aber für die Gruppe immer noch nicht lesbar oder schreibbar. Überprüfen Sie für gemeinsame Verzeichnisse die erwartete umask, Standard-ACLs oder anwendungsspezifische Dateierstellungseinstellungen:

getfacl /srv/shared_project
setfacl -d -m g:developers:rwx /srv/shared_project

Standard-ACLs sind oft das fehlende Puzzleteil in kollaborativen Verzeichnissen, da sie Berechtigungen auf neue Dateien und Verzeichnisse anwenden, die unter dem Pfad erstellt werden.

3. Das Sticky Bit

Das Sticky Bit (oder Save Text Attribute) wird fast ausschließlich auf gemeinsamen Verzeichnissen verwendet, um das Löschen von Dateien zu kontrollieren.

Wenn das Sticky Bit für ein Verzeichnis gesetzt ist, kann nur der Besitzer einer Datei in diesem Verzeichnis oder der Root-Benutzer diese Datei löschen oder umbenennen, selbst wenn das Verzeichnis selbst Schreibzugriff für 'Andere' (o+w) erlaubt.

Praktischer Anwendungsfall: Öffentliche gemeinsame Verzeichnisse wie /tmp oder Abteilungs-Upload-Ordner, in denen Benutzer nur Dateien verwalten können sollten, die sie selbst erstellt haben.

Beispiel: Das `/tmp`-Verzeichnis

Das Verzeichnis /tmp hat oft Berechtigungen wie 1777. Die 1 zeigt an, dass das Sticky Bit aktiv ist.

ls -ld /tmp
# Beispielausgabe: drwxrwxrwt 15 root root 4096 Mar 10 11:30 /tmp

Das t am Ende bestätigt, dass das Sticky Bit gesetzt ist. Ohne es könnte jeder Benutzer Dateien löschen, die von anderen Benutzern in /tmp erstellt wurden.

Das Sticky Bit setzen: Verwenden Sie den oktalen Wert 1 in Kombination mit den Standardberechtigungen (z. B. wird aus 777 1777):

chmod 1777 /var/public_uploads

Umfassende Verwaltung: Kombinieren spezieller Berechtigungen

Spezielle Berechtigungen werden oft kombiniert. Die vierte führende Ziffer ist die Summe der gewünschten speziellen Bits (4+2+1 = 7).

Gewünschte Berechtigungen	Oktaler Wert
Standard `rwxr-xr-x` (755)	`755`
SUID + `rwxr-xr-x`	`4755`
SGID + `rwxr-xr-x`	`2755`
Sticky Bit + `rwxrwxrwx`	`1777`
SUID + SGID + Sticky Bit + `rwx` (Selten notwendig)	`7777`

Beispiel für die Kombination von SGID und Sticky Bit für gemeinsame Ordner:

Um ein sicheres, gemeinsames Kollaborationsverzeichnis zu erstellen, in dem alle Benutzer Teil der Gruppe 'team' sind, neue Dateien die Gruppe 'team' erben und Benutzer die Dateien anderer nicht löschen können:

Gruppenbesitz setzen: chgrp team /data/projectX
SGID (2) + Standard rwx (7) + Sticky Bit (1) anwenden $\rightarrow 2+1 = 3$ für die speziellen Bits.
- Verwendung der expliziten Summe: SGID (2) + Sticky Bit (1) = 3. Standardberechtigungen 775.
- Gesamtbefehl: chmod 3775 /data/projectX

Wenn Sie dies mit ls -ld anzeigen, sollten Sie sowohl s an der Gruppenausführungsposition als auch t an der Ausführungsposition für Andere sehen:

drwxrwsr-t 2 root team 4096 Mar 10 11:30 /data/projectX

Wenn das Ausführungsbit fehlt, zeigt die Anzeige ein großes S oder T. Dies ist normalerweise ein Warnsignal für Verzeichnisse, da die Ausführungsberechtigung steuert, ob Benutzer das Verzeichnis durchlaufen können.

Häufige Fehler, die zu echten Vorfällen führen

Der gefährlichste Fehler ist die Verwendung von SUID, um die Entwicklung einer ordnungsgemäßen Autorisierung zu vermeiden. Wenn ein Wartungsskript eine anwendungs eigene Datei rotieren muss, machen Sie nicht das gesamte Skript für jeden Benutzer effektiv zu root. Geben Sie der Anwendung einen kontrollierten Service-Befehl, verwenden Sie eine enge sudoers-Regel oder ändern Sie den Besitz, sodass das Servicekonto die Aufgabe ohne Root ausführen kann.

Ein weiterer häufiger Fehler ist, gemeinsame Verzeichnisse ohne das Sticky Bit weltweit beschreibbar zu machen:

chmod 777 /srv/uploads

Das erscheint während des Testens praktisch. In der Produktion kann jeder lokale Benutzer, der auf das Verzeichnis zugreifen kann, Dateien eines anderen Benutzers umbenennen oder löschen. Wenn das Verzeichnis wirklich von vielen nicht verwandten Benutzern beschreibbar sein muss, ist 1777 normalerweise die sicherere Basislinie:

chmod 1777 /srv/uploads

Für team eigene Verzeichnisse ist 2775 plus eine echte Gruppe oft besser als weltweites Schreiben. Fügen Sie das Sticky Bit nur hinzu, wenn Teammitglieder die Dateien der anderen nicht löschen sollen. Manche Teams wünschen sich gemeinsame Aufräumrechte, andere nicht. Das Berechtigungsmodell sollte zu diesem Arbeitsablauf passen.

Backups und Bereitstellungen können auch spezielle Berechtigungen beschädigen. Einige Archiv- und Kopierwerkzeuge bewahren Modi standardmäßig; andere tun dies nur, wenn Sie die richtigen Flags übergeben. Überprüfen Sie nach der Wiederherstellung eines Systems oder der Bereitstellung eines Binärpakets explizit die speziellen Bits:

stat -c '%A %a %U %G %n' /usr/bin/passwd /tmp /srv/shared_project

Wenn /tmp als 0777 statt 1777 zurückkommt, ist das kein kosmetischer Unterschied. Benutzer können sich gegenseitig in die Dateien eingreifen. Wenn ein erforderliches SUID-Bit bei einem Systemdienstprogramm fehlt, verlieren normale Benutzer möglicherweise plötzlich erwartetes Verhalten. Wenn ein unerwartetes SUID-Bit auf einer Datei in /home, /tmp oder einem Anwendungs-Upload-Pfad erscheint, behandeln Sie es als verdächtig, bis das Gegenteil bewiesen ist.

Prüfung ohne in der Ausgabe zu ertrinken

Ein vollständiger Dateisystemscan kann verrauscht sein, insbesondere auf Build-Maschinen und Entwickler-Workstations. Beginnen Sie mit den Bereichen, die am wichtigsten sind:

sudo find /usr /bin /sbin /opt -type f \( -perm -4000 -o -perm -2000 \) -ls 2>/dev/null
sudo find /tmp /var/tmp /dev/shm -type f \( -perm -4000 -o -perm -2000 \) -ls 2>/dev/null

Der erste Befehl überprüft normale ausführbare Speicherorte. Der zweite überprüft beschreibbare temporäre Bereiche, in denen eine privilegierte ausführbare Datei viel besorgniserregender wäre. Auf einem sauberen Server sollten benutzerdefinierte SUID-Dateien in weltweit beschreibbaren Pfaden selten sein. Wenn Sie eine finden, überprüfen Sie den Besitz, die Paketquelle, den Änderungszeitpunkt und ob sie in Ihrer Konfigurationsverwaltung auftaucht.

Suchen Sie für Verzeichnisse nach weltweit beschreibbaren Pfaden ohne das Sticky Bit:

sudo find / -xdev -type d -perm -0002 ! -perm -1000 -ls 2>/dev/null

Das bedeutet nicht, dass jedes Ergebnis ein Einbruch ist. Es bedeutet, dass jedes Ergebnis einen Grund verdient. Einige Anwendungsverzeichnisse sind absichtlich von einer Servicegruppe beschreibbar, aber öffentlich beschreibbare Verzeichnisse ohne Sticky-Schutz sind eine häufige Gefahrenquelle.

Best Practices für die Sicherheit spezieller Berechtigungen

Aufgrund der erhöhten Privilegien, die SUID und SGID gewähren, müssen sie mit äußerster Vorsicht verwaltet werden.

SUID-Geltungsbereich einschränken: Setzen Sie SUID nur auf kompilierte Binärausführbare, die für den Standardbetrieb notwendig sind (wie passwd, ping). Wenden Sie SUID niemals auf interpretierte Skripte (Shell, Python, Perl) an, es sei denn, sie sind in einen sicheren Wrapper-Ausführbaren eingebettet, der Eingaben validiert.

Regelmäßig prüfen: Scannen Sie das Dateisystem regelmäßig mit dem Befehl find auf ungewöhnliche SUID/SGID-Dateien:

# Alle Dateien mit gesetztem SUID finden
find / -perm /4000 2>/dev/null
# Alle Dateien mit gesetztem SGID finden
find / -perm /2000 2>/dev/null

SGID für Gruppenkonsistenz verwenden: Bevorzugen Sie SGID gegenüber der manuellen Verwaltung des Dateigruppenbesitzes in gemeinsamen Datenstrukturen; es automatisiert die Gruppenvererbung.
Sticky Bit für öffentlich beschreibbare Bereiche: Das Sticky Bit ist für jedes Verzeichnis unerlässlich, das für die allgemeine Benutzernutzung bestimmt ist, bei dem das Löschen durch Nicht-Besitzer eingeschränkt werden muss (z. B. /tmp, /var/tmp).
SGID mit ACLs kombinieren, wenn Zusammenarbeit wichtig ist: SGID kümmert sich um den Gruppenbesitz; Standard-ACLs kümmern sich um die Berechtigungen, die neue Dateien erhalten.
Benutzerdefinierte Ausnahmen nachverfolgen: Wenn Ihre Organisation eine benutzerdefinierte SUID- oder SGID-Binärdatei genehmigt, dokumentieren Sie den Zweck, den Besitzer, den erwarteten Pfad und die Bereitstellungsquelle. Geheimnisvolle Privilegien sind der Teil, der später weh tut.

Spezielle Berechtigungen sind nützlich, weil sie präzise sind. Halten Sie sie so. Verwenden Sie SUID für enge Privilegienübergänge, SGID für gemeinsamen Besitz und das Sticky Bit für gemeinsame Verzeichnisse, bei denen Löschrechte abgesichert werden müssen.