# File Security Deep Dive: Wenn Berechtigungen zur Waffe werden

TL;DR / Management Summary Ein einfaches chmod kann über die Sicherheit des gesamten Unternehmens entscheiden. In diesem Modul verlassen wir die Grundlagen und betrachten Dateirechte aus der Angreifer-Sicht. Wir analysieren, wie ein falsch gesetztes SUID-Bit zur vollständigen Systemübernahme (Privilege Escalation) führt, warum eine zu lockere umask Geheimnisse in Log-Files verrät und wie man mit automatisierten Scans “faule Eier” in der Berechtigungsstruktur findet.

# 1. Einführung & Architektur

Die Macht des SUID-Bits.

SUID (Set User ID) ist ein mächtiges Feature: Es erlaubt einem Programm, mit den Rechten des Besitzers zu laufen.

• Legitim: /usr/bin/passwd (muss /etc/shadow ändern).
• Gefährlich: /usr/bin/python oder /usr/bin/vim mit SUID-Bit (erlaubt Root-Shell).

# Der Angriffs-Vektor (Mermaid)

graph TD
    A[Unprivileged User: bob] --> B[Find SUID Binary: /opt/tools/helper]
    B -->|Owned by| C[User: root]
    B -->|Exploit / Escape| D[Execute Shell within Binary]
    D --> E[Result: Root Shell for bob]
    subgraph "Hardening"
        F[Search for SUID]
        G[Remove unnecessary bits]
        H[Secure umask]
    end
    F/G/H --- B

# 2. Sicherheits-Audit: SUID/SGID finden

Was darf als Root laufen?

Ein Senior Admin scannt sein System regelmäßig nach verdächtigen SUID-Dateien.

# Suchbefehl

# Findet alle Dateien mit SUID-Bit (4000) oder SGID-Bit (2000)
find / -type f \( -perm -4000 -o -perm -2000 \) -ls 2>/dev/null

# 3. umask: Sicherheit ab der ersten Sekunde

Default-Rechte einschränken.

Die umask entscheidet, welche Rechte eine neu erstellte Datei nicht bekommt.

# Systemweit setzen

Datei: /etc/profile oder /etc/login.defs

UMASK 027

# 4. Day-2 Operations: World-Writeable Files

Das Scheunentor schließen.

Dateien, in die jeder schreiben darf, sind ideale Verstecke für Malware.

# Suche nach ‘World-Writeable’

# Findet Dateien, die für 'Others' beschreibbar sind
find / -type f -perm -o+w -ls 2>/dev/null

Ausnahme: /tmp und /var/tmp – diese müssen beschreibbar sein, sollten aber das Sticky Bit (Artikel 283) haben.

# 5. Troubleshooting & “War Stories”

Wenn die Härtung den Betrieb stört.

# Story 1: “Der Backup-Restore ohne Metadaten”

Symptom: Nach einem Restore läuft das System, aber User können ihre Passwörter nicht mehr ändern (passwd schlägt fehl). Ursache: Das Backup-Tool hat das SUID-Bit von /usr/bin/passwd nicht mitgesichert oder wiederhergestellt. Lösung: chmod u+s /usr/bin/passwd. Lerneffekt: Nutzen Sie für Backups immer Tools, die SELinux-Labels und Special-Bits unterstützen (rsync -aX, tar --xattrs).

# Story 2: “Das Log-Geheimnis”

Symptom: Ein unprivilegierter User kann in /var/log/myapp/ Datenbank-Passwörter aus den Logs lesen. Ursache: Die Applikation wurde mit umask 022 gestartet. Die Logs sind für alle lesbar (644). Lösung: Starten Sie den Dienst mit einer restriktiven Umask (z.B. via systemd UMask=0027) oder nutzen Sie ACLs (Artikel 314).

# 6. Fazit & Empfehlung

• SUID: Entfernen Sie das SUID-Bit von allen Programmen, die es nicht zwingend brauchen (chmod u-s).
• umask: Setzen Sie in Enterprise-Umgebungen standardmäßig 027.
• Automation: Nutzen Sie Tools wie Lynis oder OpenSCAP (Artikel 179), um Berechtigungsfehler automatisch zu finden.

# Anhang: Cheatsheet