Der ADMIN 05/13 wirft einen Blick auf die frei verfügbaren Cloud-Frameworks von Eucalyptus über OpenNebula bis OpenStack. Gute Aussichten für skalierbare ... (mehr)

Aufgeteilt

Ein schönes Beispiel für die Abschottung (engl. Compartmentalisation) stellt das Programm »rwhod« dar. Dieser System-Daemon ist dafür zuständig, Systeminformationen zu ermitteln. Die Informationen umfassen, welcher Benutzer aktuell angemeldet ist sowie Zeitraum und Zeitpunkt des Logons. Um den Daemon auf Capsicum umzustellen, wurde zuerst der Code bereinigt und die zu schützenden Bereiche in Funktionen unterteilt: Die zwei wesentlichen Funktionen sind »void receiver_process(void)« zum Empfang und »void sender_process(void)« zum Versenden der angeforderten Informationen an einen Client.

Rechtefrage

Nachdem die Abschottung in diesem Beispiel soweit abgeschlossen ist, muss sich der Autor des Programms Gedanken darüber machen, welche Zugriffsrechte das Tool für die einwandfreie Funktion benötigt. Hier gilt es, ein besonderes Augenmerk auf die Funktion »void receiver_process(void)« zu legen, weil sie Daten in die Datei »whod.<Hostname>« im Verzeichnis »/var/rwho« schreibt.

Eingangs wurde erläutert, dass ein Filedeskriptor, der zum Schreiben in eine Datei angelegt wird, die Möglichkeit bietet, eine Datei auszulesen. Für Schadcode ist dieser Sachverhalt willkommen, weil so Informationen unerwünscht weiterverbreitet werden können. Mit der Capsicum-Funktion »cap_rights_limit()« lässt sich genau dies verhindern, wenn man die Flags »CAP_WRITE | CAP_FTRUNCATE | CAP_FSTAT« setzt. Siehe hierzu den vollständigen Quellcode [4] ab Zeile 404:

if (cap_rights_limit(whod,
 CAP_WRITE | CAP_FTRUNCATE | CAP_FSTAT) < 0
 && errno != ENOSYS) {
  syslog(LOG_WARNING, "cap_rights_limit: %m");
  exit(1);
}

Die Flags besagen, dass der Filedeskriptor »whod« nur zum Schreiben in die Datei (»CAP_WRITE« ), zum Ändern der Dateigröße (»CAP_FTRUNCATE« ) und zum Abrufen der Statusinformationen (»CAP_FSTAT« ) genutzt werden darf. Jede andere Operation wird unterbunden. Auch für den Fall, dass der Schadcode versuchen sollte, die Flags zu manipulieren, gibt es keine Chance. Flags, die einmal gesetzt wurden, lassen sich nicht mehr verändern.

Weiterhin muss klar definiert sein, welche Dateioperationen im Verzeichnis »/var/whod« ausgeführt werden dürfen. Dazu dient der Code ab Zeile 353 (Listing 2).

Listing 2

Dateioperationen

if (cap_rights_limit(dirfd,
 CAP_CREATE | CAP_WRITE | CAP_FTRUNCATE |
 CAP_SEEK | CAP_LOOKUP | CAP_FSTAT) < 0 &&
 errno != ENOSYS) {
  syslog(LOG_WARNING, "cap_rights_limit: %m");
  exit(1);
}
if (cap_enter() < 0 && errno != ENOSYS) {
 syslog(LOG_ERR, "cap_enter: %m");
 exit(1);
}

Diese wenigen Zeile C-Code sind dafür verantwortlich, dass im bereits geöffneten Verzeichnis mit dem Filehandle »dirfd« Dateien angelegt oder ergänzt werden dürfen. Ein Auslesen der angelegten Dateien ist vom Programm aus aber nicht möglich.

Ä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

Google+

Ausgabe /2019