Capability-based security

Capability-based security (deutsch Rechtebasierende Sicherheit[-srichtlinien]) ist ein Sicherheitskonzept aus dem Bereich der Computeradministration.

Eine Fähigkeit / ein Recht (englisch capability), die auch in manchen Systemen als Schlüssel bekannt ist, ist ein kommunizierbarer und unveränderbarer Authentifizierungstoken. Dieser bezieht sich auf einen Wert, der ein Objekt und ein dazu passendes Set von Zugriffsrechten darstellt. Ein Computerprogramm des Benutzers, das auf einem Fähigkeiten-basierenden Betriebssystem läuft, muss dementsprechende Fähigkeiten/Rechte haben, um auf Objekte zugreifen zu können.

Rechtebasierende Sicherheit bezieht sich auf das Prinzip, dass Computerprogramme nach dem Prinzip der "minimalen Rechte" (engl. principle of least privilege) untereinander kommunizieren und sich dementsprechend Fähigkeiten/Rechte zuweisen und dass das Betriebssystem die passende Infrastruktur hat, um effektiv und sicher arbeiten zu können. Fähigkeiten-basierende Sicherheit steht im Kontrast zu der Ring/Domain Methode (engl. hierarchical protection domains).

Die meisten Betriebssysteme implementieren Hilfsmittel, die diesen Fähigkeiten ähneln. Diese bieten oft nicht genügend Support an, um Fähigkeiten/Rechte zwischen dem Betriebssystem unbekannte Instanzen auszutauschen, um damit die primäre Stelle für Zugriffsrechte zu sein. Im Gegensatz dazu ist eine Fähigkeiten-basierendes System, dafür ausgerichtet.

Die Fähigkeiten/Rechte, um die es in diesem Artikel geht, sollten nicht mit POSIX vertauscht werden.

Rechte und rechtebasierende Sicherheit

Rechte verbessern die Systemsicherheit, indem sie anstelle von veränderbaren Referenzen verwendet werden. Eine veränderbare Referenz (z. B. ein Pfadname) identifiziert ein Objekt, gibt aber nicht an, welche Zugriffsrechte für dieses Objekt vorhanden sind, und das Anwenderprogramm, das diese Referenz enthält. Daher muss jeder Zugriff auf das referenzierte Objekt vom Betriebssystem auf der Grundlage der Berechtigungen des anfragenden Programms validiert werden, das typischerweise über die Verwendung einer Zugriffssteuerungsliste (ACL) passiert. Im Gegenteil dazu, ist in einem System mit Rechten der reine Besitz gewisser Rechte ausreichend, um auf referenzierte Objekte zugreifen zu können. Theoretisch werden in diesen System keine Zugriffssteuerungslisten or ähnlichen Technologien vonnöten, da alle Entitäten nur die Fähigkeiten, die sie tatsächlich benötigen, besitzen.

Ein Recht/eine Fähigkeit wird typischerweise als eine privilegierte Datenstruktur implementiert, die aus zwei Teilen besteht, der eine spezifiziert Zugriffsrechte und der andere identifiziert das zuzuordnende Objekt eindeutig. Der Benutzer greift nicht direkt auf die Datenstruktur oder das Objekt zu, sondern über einen Handle. In der Praxis wird es viel wie ein Dateihandle in einem traditionellen Betriebssystem (ein traditioneller Handle) verwendet, aber um auf jedes Objekt auf dem System zuzugreifen. Die Fähigkeiten werden typischerweise vom Betriebssystem in einer Liste gespeichert, wobei ein gewisser Mechanismus vorhanden ist, um zu verhindern, dass das Programm den Inhalt der Fähigkeit direkt ändert. Einige Systeme basieren ebenfalls auf einer fähigkeitsorientierten Adressierung (≈Hardwareunterstützung für Fähigkeiten), wie das Plessey System 250.

Programme, die Fähigkeiten besitzen, können Funktionen auf diesen durchführen, wie z. B. diese an andere Programme weitergeben, sie in eine weniger privilegierte Version umwandeln oder sie löschen. Das Betriebssystem muss sicherstellen, dass nur bestimmte Operationen für die Fähigkeiten im System auftreten können, um die Integrität der Sicherheitspolitik aufrechtzuerhalten.

Einführung in rechtebasierende Sicherheit

Eine Fähigkeit/Ein Recht ist definiert als eine geschützte Objektreferenz, die aufgrund ihrer Eigenschaft einem Prozess die Erlaubnis/Fähigkeit gibt, um mit einem Objekt zu interagieren. Dies könnten das Lesen von Daten, die mit einem Objekt verbunden sind, das Ändern des Objekts, das Ausführen der Daten und andere denkbare Zugriffsrechte sein. Die Fähigkeit besteht daher logischerweise aus einer Referenz, die ein bestimmtes Objekt eindeutig identifiziert und ein oder mehrerer dieser Rechte besitzt.

Angenommen, in dem Speicherplatz eines Programmes existiert der folgende String:

/etc/passwd

Obwohl dies ein eindeutiges Objekt auf dem System identifiziert, gibt es keine Zugriffsrechte an und ist daher keine Fähigkeit. Angenommen, es gibt stattdessen die folgenden zwei Werte:

/etc/passwd
O_RDWR

Dies identifiziert ein Objekt zusammen mit dessen Zugriffsrechten. Es ist jedoch noch keine Fähigkeit, weil Besitz dieser Werte nichts darüber sagt, ob dieser Zugang tatsächlich legitim wäre.

Nehmen wir nun an, dass das Anwenderprogramm die folgende Anweisung erfolgreich ausführt:

int fd = open("/etc/passwd", O_RDWR);

Die Variable fd enthält nun den Index eines Dateihandle in der Dateihandletabelle des Prozesses. Dieser Dateihandle ist eine Fähigkeit. Seine Existenz in der Dateihandletabelle des Prozesses reicht aus, um zu wissen, dass der Prozess tatsächlich einen legitimen Zugriff auf das Objekt hat. Ein wesentliches Merkmal dieser Anordnung ist, dass sich die Dateihandletabelle im Kernspeicher befindet und nicht direkt vom Anwenderprogramm manipuliert werden kann.

Austausch von Fähigkeiten zwischen Prozessen

In traditionellen Betriebssystemen kommunizieren Programme oft miteinander, indem Pfadnamen oft als Befehlszeilenparameter übergeben oder über Sockets gesendet werden. Diese Referenzen sind keine Fähigkeiten und müssen validiert werden, bevor sie verwendet werden können. In diesen Systemen ist die zentrale Frage, "auf wessen Autorität eine gegebene Referenz zu beurteilen ist?" Dies wird ein kritisches Thema bei Prozessen, die von zwei unterschiedlichen Entitäten mit unterschiedlichen Rechten ausgeführt werden. Dies kann zu einem häufig auftretenden Programmierfehler führen, der als Confused deputy problem(deutsch verwirrtes Stellvertreter Problem) bezeichnet wird und zu Sicherheitslücken führen kann.

In einem fähigkeitenbasierenden System werden die Fähigkeiten zwischen Prozessen und dem Speicherung über einen Mechanismus übergeben, der vom Betriebssystem bekannt ist, um die Integrität dieser Fähigkeiten aufrechtzuerhalten.

Ein neuartiger Ansatz zur Lösung dieses Problems beinhaltet die Verwendung eines orthogonal persistierenden Betriebssystems. (Das wurde in der Flex-Maschine realisiert) In so einem System besteht keine Notwendigkeit Entitäten zu verwerfen und ihre Fähigkeiten ungültig zu machen und benötigen daher einen ACL-ähnlichen Mechanismus, um diese Fähigkeiten zu einem späteren Zeitpunkt wiederherstellen zu können. Das Betriebssystem behält die Integrität und Sicherheit der Fähigkeiten, die im gesamten Speicher enthalten sind, sowohl flüchtige als auch nichtflüchtige; Zum Teil durch die Durchführung aller Serialisierungsaufgaben, anstatt die Benutzerprogramme dies machen zu lassen, wie dies bei den meisten Betriebssystemen der Fall ist. Da die Anwenderprogramme von dieser Verantwortung entlastet werden, besteht keine Notwendigkeit ihre Rechte und Fähigkeiten noch ihre Zugangsanfragen zu validieren.

POSIX vs. Capsicum Fähigkeiten

POSIX draft 1003.1e spezifiziert ein Konzept der Berechtigungen mit dem Namen "Fähigkeiten". Allerdings unterscheiden sich POSIX-Fähigkeiten von den Fähigkeiten in diesem Artikel. Eine POSIX-Fähigkeit ist nicht mit einem Objekt verbunden; Ein Prozess mit CAP_NET_BIND_SERVICE-Fähigkeit kann man auf dem TCP-Port 1024 zugreifen. Im Gegensatz dazu verbinden Capsicum Fähigkeiten auf FreeBSD und Linux ein echtes Fähigkeiten-System mit dem UNIX-Design und der POSIX API. Capsicum-Fähigkeiten sind eine verfeinerte Form des Dateihandles. Ein delegierbares Recht zwischen Prozessen und zusätzlichen Objekttypen, das über das klassische POSIX(z. B. Prozess) ragt, können über Fähigkeiten referenziert werden. Im Capsicum-Fähigkeitsmodus können Prozesse nicht globale Namensräume (wie z. B. den Dateinamen des Dateisystems) verwenden, um Objekte zu finden, und müssen stattdessen vererbt werden oder sie bekommen die Objekte von anderen Prozessen.

Forschung und kommerzielle Systeme

Tahoe-LAFS - Open-Source Fähigkeiten-basierende Filesystem
GNOSIS
- KeyKOS
  - EROS - The Extremely Reliable Operating System - KeyKOS Nachfolger
    - CapROS - EROS Nachfolger, dass den EROS Code weiterentwickelt hat für kommerzielle Zwecke
    - Coyotos - EROS Nachfolger für Forschungszwecke
Cambridge CAP computer
Carnegie Mellon University C.mmp mit Hydra (Betriebssystem)
Carnegie Mellon University CM* with StarOS
IBM System/38 and AS/400
Intel iAPX 432
Plessey System 250
Flex
L4 microkernel family - Open Kernel Labs - OKL4 and NICTA - seL4, TU-Dresden - Fiasco.OC
Amoeba - verteiltes Betriebssystem
CloudABI secure runtime environment
Google Fuchsia^[1]