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)

Vorher planen

Capsicum setzt daher voraus, dass man Applikationen sehr genau plant. Diese Aufgabe ist mit Sicherheit nicht trivial, da sie eine sehr genaue Analyse der Ressourcen verlangt. Dazu gehört der Einsatz von geschütztem Shared Memory anstelle eines gemeinsamen, öffentlich zugänglichen Speicherbereichs zum Datenaustausch. Capsicum gibt dem Programmierer die Wahlfreiheit, ob er das FreeBSD-eigene Berechtigungssystem verwendet oder die Bibliothek »libcapsicum« einsetzt.

Applikationen mit zweifelhaften Privilegien lassen sich so umbauen, dass sie »cap_enter()« direkt verwenden. So entsteht eine Applikation, deren einzelne Prozesse im Capability-Mode laufen und spezielle Berechtigungen über ihre Filedeskriptoren vererben. Diese Vorgehensweise eignet sich gut für einfach gestrickte Applikationen, die nach folgendem Schema ablaufen: Alle Ressourcen öffnen und in einer Schleife alle ein- und ausgehenden Daten verarbeiten – ähnlich einer UNIX-Pipeline oder bei einer Interaktion mit einem Netzwerk. Der Geschwindigkeitsverlust durch Capsicum ist sehr gering, wenn man die Berechtigungen beim Zugriff auf die Ressourcen einschränkt.

Anhand des FreeBSD-Tools zur Netzwerkanalyse »tcpdump« wird dieses Ziel im Folgenden näher beschrieben. Tcpdump ist nach dem genannten Schema aufgebaut und daher einfach auf Capsicum umzustellen: Das Programm nutzt den Berkeley Packet Filter »bpf« , um die über ein Netzwerk transportierten Daten zu analysieren. Dazu teilt Tcpdump dem Paketfilter ein Suchmuster mit. Im nächsten Schritt wird der Filter als Eingabequelle definiert, um die Informationen zur weiteren Verarbeitung an »tcpdump« zu senden. Schließlich werden die eingehenden Daten in einer Schleife interpretiert, aufbereitet und auf der Console dargestellt. Somit lässt sich die Anwendung mit zwei zusätzlichen Zeilen Programmcode in den Capsicum-Capability-Mode übertragen:

if (cap_enter() < 0)
 error("cap_enter: %s",
  pcap_strerror(errno));

Diese beiden Zeilen werden vor der Schleife eingefügt, welche die Analyse des Datenverkehrs durchführt:

status = pcap_loop(pd, cnt,
 callback, pcap_userdata);

Damit erhöht sich die Sicherheit beträchtlich. Parsen und Analysieren von Datenpaketen stellt meistens eine Sicherheitslücke dar, weil viele Speicherzugriffe durch C-Pointer und Kopieraktionen durchgeführt werden. Wie zuvor erläutert, unterbindet Capsicum den Zugriff auf privilegierte Speicherbereiche, was durch den Aufruf von »cap_enter()« realisiert wird. Um auch die Kommunikation auf STDIN (Standardeingabe), STDOUT (Standardausgabe) und STDERR (Standardfehlerausgabe) zu beschränken, sollte man Listing 1 vor dem ersten Aufruf von »cap_enter()« einfügen.

Listing 1

Standardkanäle limitieren

if (cap_rights_limit(STDIN_FILENO,
 CAP_FSTAT) < 0)
  error("cap_new: unable to limit STDIN_FILENO");
if (cap_rights_limit(STDOUT_FILENO,
 CAP_FSTAT | CAP_SEEK | CAP_WRITE) < 0)
  error("cap_new: unable to limit STDOUT_FILENO");
if (cap_rights_limit(STDERR_FILENO,
 CAP_FSTAT | CAP_SEEK | CAP_WRITE) < 0)
  error("cap_new: unable to limit STDERR_FILENO");

Mit der hier verwendeten Funktion »cap_rights_limit()« wird der Lesezugriff auf das STDIN-Gerät unterbunden, während Schreiboperationen auf die Ausgabegeräte STDOUT und STDERR sinnvollerweise erlaubt werden.

Reingeschaut

Eine Analyse mit dem um den Parameter »-C« erweiterten FreeBSD-Kommando »procstat« bestätigt diesen Sachverhalt und ist als Screenshot in Abbildung 3 zu sehen. In der ersten und zweiten Spalte sind die Prozess-ID und der Prozessname zu sehen; die dritte Spalte zeigt den Filedeskriptor. In diesem Beispiel sind das Standardeingabe (FD = 0), Standardausgabe (FD = 1), Standardfehlerausgabe (FD = 2) und der Treiber »bpf« für den Berkeley-Paketfilter (FD = 3); Spalte vier beschreibt die Art des Filedeskriptors, in Spalte »FLAGS« wird dargestellt, welche FreeBSD-Berechtigungen gesetzt sind. Desweiteren weist der Buchstabe »c« darauf hin, dass Capsicum für diesen Filedeskriptor aktiv ist.

Abbildung 3: Die Ausgabe von procstat eines durch Capsicum abgesicherten tcpdump.

Die Spalte »CAPABILITIES« zeigt an, welche der Capsicum-Berechtigungen gesetzt sind. Die Angabe »FS« (CAP_FSTAT) bedeutet, dass der Status des Filedeskriptors abgefragt werden darf, »wr« (CAP_WRITE) steht für Schreibberechtigung und »se« (CAP_SEEK) bedeutet, dass der Dateizeiger gesetzt werden darf. Eine Übersicht aller Capsicum-Berechtigungen findet sich unter [2]. Die letzten beiden Spalten zeigen das Protokoll und den Gerätetreiber an, der für den jeweiligen Filedeskriptor verwendet wird.

Bei der Verwendung von Capsicum tritt aber auch ein unschöner Nebeneffekt auf, der sich speziell bei »tcpdump« deutlich zeigt: Es wird auch der Zugriff auf den Name-Service-Switch unterbunden. Im Fall von »tcpdump« betrifft das die Umwandlung von IP-Adressen in voll qualifizierte Hostnamen. Dies lässt sich aber umgehen, indem man Anfragen an einen lokalen Domain-Name-Server sendet.

Ä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