# Sudoers Masterclass: Granulare Rechteverwaltung

TL;DR / Management Summary Wer die /etc/sudoers beherrscht, beherrscht die Sicherheit des Servers. Während einfache Regeln (Artikel 284) für Standalone-Systeme reichen, erfordern Enterprise-Infrastrukturen eine strukturierte Herkunft der Rechte. Wir nutzen Aliasse, um User-Gruppen und Befehlslisten logisch zu bündeln, und verwalten diese modular im Verzeichnis sudoers.d. Das Ziel: Ein auditierbares, sicheres Regelwerk, das dem Admin nur die Macht gibt, die er für seine aktuelle Aufgabe braucht.

# 1. Einführung & Architektur

Die Struktur der Macht.

Sudoers-Regeln werden von oben nach unten gelesen. Die letzte passende Regel gewinnt.

# Die Alias-Hierarchie (Mermaid)

graph TD
    A[Sudoers Logic] --> B[User_Alias: WEB_ADMINS]
    A --> C[Cmnd_Alias: RESTART_SERVICES]
    A --> D[Runas_Alias: DB_USER]
    B --> E[Rule: WEB_ADMINS ALL=(DB_USER) RESTART_SERVICES]
    subgraph "The Actors"
        B1[Alice, Bob] --> B
    end
    subgraph "The Actions"
        C1[/usr/bin/systemctl restart] --> C
    end

# 2. Alias-Typen im Detail

Ordnung durch Abstraktion.

Legen Sie Aliasse am Anfang der Datei an, um sie später in Regeln zu verwenden.

# User_Alias

Bündelt Benutzer unabhängig von ihrer GID.

User_Alias IT_STAFF = admin, backup_user, %it-dept

# Cmnd_Alias

Definiert eine Liste von erlaubten Befehlen. Nutzen Sie immer absolute Pfade!

Cmnd_Alias NETWORKING = /usr/sbin/ip, /usr/sbin/ifconfig, /usr/bin/ping

# 3. Modularität mit /etc/sudoers.d/

Weg von der monolithischen Datei.

Ändern Sie die Hauptdatei /etc/sudoers so wenig wie möglich. Nutzen Sie stattdessen modulare Dateien für Applikationen oder Teams.

# Best Practice

1. Stellen Sie sicher, dass am Ende von /etc/sudoers die Zeile @includedir /etc/sudoers.d steht.
2. Erstellen Sie Dateien wie /etc/sudoers.d/90-ansible:

# User 'ansible' darf alles ohne PW (für Automation)
ansible ALL=(ALL) NOPASSWD: ALL

# 4. Day-2 Operations: Globale Defaults

Das Verhalten von Sudo anpassen.

Nutzen Sie die Defaults Sektion für Security-Policies.

# Beispiel: Custom Sudo Settings

# Beleidige den User bei falschem Passwort (nicht für Prod empfohlen!)
# Defaults insults

# Sende eine E-Mail bei jedem Sudo-Aufruf
Defaults mail_always
Defaults mailto="security@company.com"

# Verhindere Umgebungsvariablen-Spoofing
Defaults env_reset

# 5. Troubleshooting & “War Stories”

Wenn die Logik hinkt.

# Story 1: “Die Shell-Escape Falle”

Symptom: Ein User hat Sudo-Rechte für /usr/bin/vi, um Configs zu ändern. Plötzlich findet der Admin heraus, dass der User Root-Zugriff auf das gesamte System hat. Ursache: Viele Programme (Vim, Less, Man) erlauben es, eine Shell aus dem Programm heraus zu starten (Escape). Da Vim als Root läuft, ist auch die neue Shell Root. Lösung: Nutzen Sie das Flag NOEXEC in der Regel oder nutzen Sie spezialisierte Tools wie sudoedit statt dem direkten Aufruf des Editors. WEB_ADMINS ALL=(ALL) sudoedit /etc/nginx/nginx.conf

# Story 2: “Reihenfolge-Albtraum”

Symptom: Ein Admin gibt einer Gruppe Rechte, aber ein spezifischer User in dieser Gruppe bekommt trotzdem “Permission Denied”. Ursache: Eine spätere Zeile in der Sudoers-Datei entzieht die Rechte wieder (z.B. durch eine restriktive Regel für den Hostname). Lösung: Nutzen Sie sudo -l -U <username>, um zu sehen, welche Regeln für diesen User effektiv aktiv sind. Die Ausgabe ist nach Priorität sortiert.

# 6. Fazit & Empfehlung

• Sudoedit: Nutzen Sie für das Editieren von Systemdateien immer sudoedit. Es kopiert die Datei temporär, editiert sie als User und kopiert sie nur bei Erfolg zurück (Sicherer als sudo vi).
• Minimalismus: Geben Sie niemals ALL=(ALL) ALL, wenn ein spezifischer Alias für 10 Befehle ausreicht.
• Audit: Kontrollieren Sie regelmäßig die Dateien in sudoers.d/. Verwaiste Regeln von deinstallierten Tools sind ein Sicherheitsrisiko.

# Anhang: Cheatsheet