Restricted Shell (rbash) in Bash: eingeschränkte Umgebungen richtig einsetzen

1. Was eine Restricted Shell ist und wofür sie gedacht ist

Eine Restricted Shell ist eine Bash-Variante, die eine feste Menge an Aktionen verbietet, bevor überhaupt ein Kommando ausgeführt wird. Aktiviert wird sie entweder mit dem Symlink beziehungsweise Kommandonamen rbash, mit dem Startparameter bash -r, oder indem die Option restricted zur Laufzeit mit set -r gesetzt wird. Alle drei Wege führen zum selben eingeschränkten Modus, nur der Zeitpunkt der Aktivierung unterscheidet sich.

Der Zweck einer Restricted Shell ist nicht, ein vollwertiges Sandbox-System zu ersetzen, sondern gutartige Fehlbedienung zu verhindern und den Aktionsradius eines Nutzers in einem klar definierten, meist bereits vertrauenswürdigen Kontext einzuschränken. Typische Einsatzfälle sind ein eingeschränkter Login für einen externen Dienstleister, der nur ein festes Skript ausführen soll, oder ein SFTP-ähnlicher Zugang, bei dem der Nutzer sich nicht frei im Dateisystem bewegen soll.

2. Was genau eingeschränkt wird: cd, PATH, Programme mit Slash

In einer rbash-Sitzung sind konkret folgende Aktionen verboten: das Verzeichnis mit cd wechseln, die Variablen PATH, SHELL, ENV oder BASH_ENV ändern, Kommandos ausführen, deren Name einen Slash enthält (also /bin/bash oder ./script.sh), sowie die Ausgabe mit >, >> oder >| in eine neue Datei umleiten. Auch das Deaktivieren des restricted-Modus selbst über set +r ist blockiert, sobald er einmal aktiv ist.

Diese Liste zeigt bereits das Grundprinzip: rbash verbietet keine bestimmten Kommandos direkt, sondern beschränkt die Wege, wie ein Nutzer außerhalb eines vordefinierten PATH Programme aufrufen und wie er Dateien außerhalb erlaubter Verzeichnisse manipulieren kann. Innerhalb des erlaubten PATH liegende Programme laufen ganz normal weiter, weshalb der Inhalt dieses Verzeichnisses die eigentliche Sicherheitsgrenze bildet, nicht die Shell selbst.

# Minimal rbash setup for a restricted account
useradd -m -s /bin/rbash deploy-partner
mkdir -p /home/deploy-partner/bin
ln -s /usr/bin/rsync /home/deploy-partner/bin/rsync

# Only this directory is exposed via PATH, set in the user's profile
echo 'PATH=$HOME/bin' >> /home/deploy-partner/.bash_profile
echo 'export PATH' >> /home/deploy-partner/.bash_profile
chmod 555 /home/deploy-partner/bin  # not writable by the user

3. Typischer Einsatzfall: eingeschränkte SSH-Zugänge für Dienstleister

Ein häufiges Szenario ist ein externer Dienstleister, der per SSH nur ein bestimmtes Deployment-Skript ausführen soll, ohne freien Shell-Zugriff auf den Server zu bekommen. Kombiniert mit der SSH-Option ForceCommand in sshd_config oder direkt in der authorized_keys-Datei über command="..." lässt sich der Login gezielt auf genau ein Kommando begrenzen, während rbash zusätzlich verhindert, dass innerhalb dieses Kommandos beliebige andere Programme nachgeladen werden.

Wichtig ist dabei die Reihenfolge der Absicherung: ForceCommand entscheidet, was beim Login überhaupt ausgeführt wird, und rbash schränkt anschließend ein, was dieses Kommando selbst noch tun darf, falls es interaktiv wird oder eine Subshell öffnet. Beide Mechanismen zusammen sind deutlich robuster als jeder für sich allein, weil ForceCommand einen direkten Shell-Login von vornherein verhindert und rbash zusätzlich den Aktionsradius innerhalb des erlaubten Kommandos begrenzt.

# In /home/deploy-partner/.ssh/authorized_keys
command="/home/deploy-partner/bin/deploy.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-ed25519 AAAA... partner@example.com

# In sshd_config, alternative per-user ForceCommand
Match User deploy-partner
    ForceCommand /home/deploy-partner/bin/deploy.sh
    ChrootDirectory /home/deploy-partner

4. Eine rbash-Umgebung sauber einrichten

Der wichtigste Schritt beim Einrichten ist, den PATH auf ein einziges, für den Nutzer nicht schreibbares Verzeichnis mit ausschließlich geprüften Programmen zu setzen, und diesen PATH in einer Profildatei zu setzen, die selbst nicht mehr vom Nutzer verändert werden kann. Wird der PATH stattdessen interaktiv oder in einer vom Nutzer beschreibbaren Datei gesetzt, kann er ihn beim nächsten Login einfach überschreiben, bevor rbash überhaupt greift.

Zusätzlich sollten alle Skripte im freigegebenen Verzeichnis selbst defensiv geschrieben sein: kein Aufruf externer Programme mit vom Nutzer kontrollierten Argumenten, keine eval-Aufrufe auf Nutzereingaben, und wo möglich der Verzicht auf Shell-Interpreter zugunsten fest kompilierter Wrapper-Programme. rbash schränkt die Shell selbst ein, kontrolliert aber nicht, was die freigegebenen Programme intern mit ihren Argumenten anstellen.

5. Bekannte Escape-Techniken: warum rbash allein nicht ausreicht

rbash ist seit Jahren für eine ganze Reihe dokumentierter Fluchtwege bekannt. Programme, die selbst eine interaktive Shell starten können, etwa vi mit :!bash, less mit !bash, oder ftp, scp und ähnliche Werkzeuge mit eingebauten Shell-Escapes, hebeln die Restricted Shell vollständig aus, sobald sie im freigegebenen PATH stehen. Auch ssh -o ProxyCommand=... oder das Umleiten von Skript-Ausführung über source kann in bestimmten Konstellationen aus der Beschränkung ausbrechen.

Ein weiterer bekannter Weg ist, dass rbash zwar das direkte Ausführen von Programmen mit Slash verbietet, ein bereits erlaubtes Programm im PATH aber selbst wieder einen Pfad mit Slash aufrufen kann, etwa ein Editor, der über seine eigene Dateiöffnen-Funktion beliebige Pfade liest oder schreibt. Genau deshalb gilt als Grundregel: Nur Programme freigeben, die nachweislich keine Shell-Escapes, keine Dateisystem-Navigation und keine Subprozess-Aufrufe mit freien Argumenten anbieten.

6. rbash sinnvoll härten: zusätzliche Schichten statt Verlass auf eine einzige

Weil rbash allein keine harte Sicherheitsgrenze ist, gehört es in ein mehrschichtiges Konzept: eine chroot-Umgebung oder ein Linux-Namespace begrenzt zusätzlich, welche Dateien überhaupt sichtbar sind, unabhängig davon, ob ein Escape aus rbash gelingt. Auf Systemen mit systemd lassen sich Dienste zusätzlich mit NoNewPrivileges, ProtectSystem und ähnlichen Sandbox-Direktiven absichern, die auch nach einem erfolgreichen rbash-Escape wirksam bleiben.

Für SSH-Zugänge empfiehlt sich zusätzlich, den Nutzer in eine dedizierte Gruppe ohne sudo-Rechte zu stecken, das Home-Verzeichnis restriktiv zu setzen (chmod 750), und regelmäßig zu auditieren, welche Binärdateien im freigegebenen PATH tatsächlich liegen. Ein rbash-Setup, das nie überprüft wird, sammelt über die Zeit oft zusätzliche, versehentlich freigegebene Programme an, die neue Escape-Wege öffnen.

# Combine rbash with a minimal chroot for an SFTP-only user
usermod -d /home/partner -s /bin/rbash partner

# In sshd_config: chroot plus internal-sftp, no rbash escape possible
# because there is no shell at all inside the jail
Match User partner
    ChrootDirectory /home/partner
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

7. Wann eine echte Alternative zu rbash die bessere Wahl ist

Für reinen Dateitransfer ist internal-sftp von OpenSSH kombiniert mit ChrootDirectory fast immer die robustere Lösung, weil es überhaupt keine Shell startet und damit die gesamte Klasse von rbash-Escapes von vornherein entfällt. Für einzelne, klar definierte Kommandos ist ein reines ForceCommand ohne rbash oft ausreichend, solange das Kommando selbst keine interaktive Subshell anbietet.

Für stärker isolierte Umgebungen sind Container mit minimalem Root-Filesystem oder dedizierte Jump-Hosts mit strengem Audit-Logging die deutlich robustere Wahl gegenüber jeder Form von Restricted Shell, weil sie auf Kernel-Ebene statt auf Anwendungsebene isolieren. rbash bleibt dabei ein sinnvoller, leichtgewichtiger Baustein, aber nicht die alleinige Verteidigungslinie für sicherheitskritische Zugänge.

8. Typische Fehler beim Betrieb von rbash-Umgebungen

Ein häufiger Betriebsfehler ist, ein interaktives Login-Skript wie .bashrc oder .bash_profile für den restricted-Nutzer schreibbar zu lassen. Da rbash das Ändern von PATH zur Laufzeit verbietet, aber nicht das Bearbeiten der Profildatei selbst, kann ein Nutzer mit Schreibzugriff auf sein eigenes Home-Verzeichnis den PATH beim nächsten Login beliebig erweitern und die Einschränkung damit faktisch aufheben.

Ein zweiter häufiger Fehler ist, ein zu mächtiges Programm im freigegebenen PATH zu platzieren, etwa einen generischen Texteditor oder ein Archivierungswerkzeug mit eingebauter Shell-Funktion, ohne dessen Funktionsumfang vorher genau zu prüfen. Jedes zusätzliche Programm im PATH einer Restricted Shell vergrößert die Angriffsfläche, weshalb die Liste erlaubter Programme so klein wie irgend möglich gehalten werden sollte.

9. rbash im Vergleich zu anderen Isolationsmechanismen

rbash unterscheidet sich von chroot, Containern und Namespaces vor allem im Angriffsvektor, gegen den es schützt: rbash kontrolliert, welche Shell-Funktionen genutzt werden dürfen, während chroot und Container kontrollieren, welche Dateien und Ressourcen überhaupt sichtbar sind. Beide Ebenen ergänzen sich, ersetzen sich aber nicht gegenseitig, weshalb produktive Setups meist mehrere dieser Mechanismen kombinieren.

Die folgende Tabelle ordnet rbash neben den gängigsten Alternativen ein und zeigt, welcher Mechanismus für welchen Grad an benötigter Isolation die passende Wahl ist, von einfachen Fehlbedienungsschutz bis zu vollständiger Prozessisolation.

10. Zusammenfassung

11. FAQ: Restricted Shell (rbash): Das Wichtigste auf einen Blick