Sichere Shell-Skripte schreiben

Kleinvieh macht auch Mist

Holistische Systemsicherheit bedeutet, auch dem kleinsten Teil Aufmerksamkeit zu widmen, auf dass es nicht als Einfallsloch in das System dient. Ein Beispiel für kleine, wenig beachtete, aber dennoch potenziell sehr gefährliche Teile der IT sind Shell-Skripte. Sie sorgen immer wieder für ernste Sicherheitsprobleme, weshalb wir Best Practices zur sicheren Skript-Programmierung präsentieren.
Wiederkehrende Abläufe in der IT sind einerseits zeitraubend, eignen sich andererseits aber ideal für eine Automatisierung. Im März-Heft beleuchtet ... (mehr)

Einen eindrucksvollen Beleg für die mögliche Schädlichkeit von Shell-Skripten lieferte das amerikanische Softwareunternehmen Valve. Die Linux-basierte Version des Spielediensts Steam brachte ein Skript mit, das normalerweise nur für kleinere Einrichtungsaufgaben zuständig war. Verhängnisvollerweise [1] fand sich dort folgende Passage:

rm -rf "$STEAMROOT/"*

Dieses für das Löschen des Verzeichnisses "$STEAMROOT" verantwortliche Kommando bekommt Probleme, wenn die Umgebungsvariable nicht gesetzt ist. Die Bash-Shell löst dann keinen Fehler aus, sondern "zerlegt" die Umgebungsvariable einfach zu einem leeren String. Lohn der Mühen ist folgendes Kommando, das sich rekursiv durch das gesamte Dateisystem arbeitet und alle Informationen zerstört:

rm -rf "/"*.

Einige Benutzer entgingen einem Totalverlust dadurch, dass ihre Steam-Ausführungsumgebung unter SELinux-Jail lief. Andere waren nicht so glücklich, weshalb es an der Zeit ist, sich Maßnahmen zur defensiven Programmierung von Shell-Skripten näher anzusehen.

Shell-Variante festlegen

Unter unixoiden Betriebssystemen stehen Dutzende von Shells zur Verfügung, die sich nur durch die Unterstützung des POSIX-Standards ähneln und diverse proprietäre Funktionen mitbringen. Bei der Nutzung von Shell-spezifischem Code in anderen Shells tritt oft ein undefiniertes Verhalten auf. Dies mag in einer kontrollierten VM-Umgebung kein Problem sein, doch das Deployment in einem Docker- oder sonstigem Cluster ändert die Lage.

Das häufigste Problem ist die Verwendung der als Shebang bezeichneten Sequenz "#!/bin/sh", die gemäß POSIX-Standard die vom System vorausgewählte Shell betrifft. Ein Shebang ist unter Unix eine mit "#!" beginnende erste Zeile eines Skripts. Sie legt fest, welcher Interpreter für die Abarbeitung des

...

Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2021