Sicherheit: Nano-Editor für Nutzer verbieten

Datum: Tue, Mar 9, 2021

Tag(s): Sicherheit nano rnano linux server verbieten

Neulich habe ich auf einem Server eine erschreckende Entdeckung gemacht: Eine Konfigurationsdatei für eine PHP-Anwendung hatte .save Dateien gespeichert.

Da dies eine PHP-Anwendung war, wurden diese Dateien über einen Webserver ausgeliefert und jemand, der den Pfad zu den .save Files erraten konnte, konnte die Zugangsdaten zur Webanwendung und zur Datenbank herunterladen.

Zwar hatten die Zugangsdaten nur für diese eine Anwendung eine Berechtigung, konnten also nicht auf andere PHP-Anwendungen oder Datenbanken zugreifen, jedoch scheint jemand diese Zugangsdaten gefunden und ausgenutzt zu haben.

Ich musste also die .save Files löschen, Zugangsdaten abändern und die Datenbank aus einem Backup wieder herstellen.

Wie konnte das passieren?

Ich habe zum Bearbeiten der Config-Datei den Texteditor “nano” verwendet. Dabei ist mir zwischendrin wohl auch mal die Verbindung abgebrochen oder ähnliches passiert und nano hat eine “.save” als auch eine “.save.1” Datei der Konfigurationsdatei angelegt.

Da PHP-Konfigurationsdateien üblicherweise in einem Verzeichnis liegen, die der Webserver ausliefert und die Webserversoftware anscheinend keine Ausnahmen für “.save” und “.save.1” kennt, hat der Webserver die Dateien nach der Eingabe des Pfades einfach ausgeliefert.

Wie kann man das verhindern?

Es gibt zwei Möglichkeiten:

  1. Man konfiguriert den Webserver so, dass keine “.save” und “.save.1” Dateien ausgeliefert werden. Das kann man z.B. über “.htaccess” Dateien bei Apache oder nginx Regeln machen. Wäre auf jeden Fall schon mal sinnvoll.
  2. Neben “nano” gibt es auch einen zweiten Befehl, um eine beschränke nano-Variante zu öffnen: “rnano”. Diese Variante legt keine .save Dateien an und ist auch in weiteren Funktionen beschränkter als die normale Version.

rnano ist also perfekt für den Einsatz auf dem Server. Als ich von dieser Variante erfahren habe, musste ich gleich diese Weisheit teilen:

Nun möchte ich meine Server wie folgt konfigurieren: “nano” soll für den root-Nutzer gar nicht möglich sein. Dieser darf nur “rnano” verwenden - so kann diese .save-File Lücke gar nicht erst auftreten. (Natürlich macht es trotzdem Sinn, für .save Files dem Webserver mitzuteilen, diese nicht auszuliefern)

nano verbieten

Erster Versuch (Spoiler: Schlug fehl)

Zuerst sollten wir sicherstellen, dass wir mit dem Deaktivieren von nano nicht auch rnano deaktivieren.

# which nano
/usr/bin/nano
which rnano
/usr/bin/rnano

Okay - rnano hat also eine andere Binary. Mit getfacl können wir die aktuellen Zugriffsrechte prüfen:

# getfacl /usr/bin/nano
getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: usr/bin/nano
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

Aktuell kann root also auf nano zugreifen. Nun verbieten wir das:

# /bin/setfacl -m u:root:--- /usr/bin/nano

Hmmmm… Danach kann der root-Nutzer aber immer noch auf nano zugreifen - vermutlich weil root nun mal die höchsten Rechte hat und auch Owner der Datei ist…

Bei anderen Nutzern geht nach der Eingabe dieses Commands übrigens sowohl nano als auch rnano nicht. rnano hat also zwar einen anderen Pfad, aber greift wohl auch auf nano zu und geht deshalb nicht.

Mit dem folgenden Befehl kann man es wieder rückgängig machen:

# /bin/setfacl -m u:root:rwx /usr/bin/nano

Dann halt ne Alias

Mit einem Alias lernen wir nicht so gut - weil wir nicht auf unseren Fehler hingewiesen werden, dass wir rnano statt nano verwenden sollten, allerdings ist es immer noch besser als nichts.

Also im Home-Verzeichnis des jeweiligen Nutzers die .bashrc um eine Zeile erweitern:

alias nano="rnano"

Nun einmal neu verbinden - und: Tada! Bei einem Aufruf von nano kommen wir jetzt in den Eingeschränkten-Modus. Es werden also keine problematischen .save Dateien mehr angelegt.