Die Architektur des Linux-Sicherheitssystems Rule Set Based
Access Control (RSBAC)
Sicherheits-Architektur
von Amon Ott
Erschienen im Linux-Magazin
2003/01
Mehrere Sicherheitsmodelle gleichzeitig in den Kernel integrieren und auch noch alle Zugriffe detailliert protokollieren: Das freie Sicherheitssystem Rule Set Based Access Control (RSBAC) bietet angepassten Schutz für unterschiedliche Anforderungen.
Sicherheitslücken in Linux finden sich meist in Serverprogrammen und S-Bit-Tools. Der Königsweg wäre: Fehler vermeiden und Programme sofort aktualisieren, falls doch ein Bug auftritt. Da dies nicht immer gelingt, gilt es, den potenziellen Schaden zu begrenzen. Das ist die Aufgabe von Zugriffskontrollsystemen wie RSBAC[1]: Nutzt ein Angreifer Lücken in Servern oder S-Bit-Tools, dann soll er nur minimalen Zugang zum System erhalten. Selbst ein erfolgreicher Einbruch hat so nur begrenzte Auswirkungen. Der Schutz wird direkt im Betriebssystemkern implementiert.
Der unveränderte Linux-Kernel verhindert bereits viele Zugriffe auf diverse Ressourcen wie Dateien, Verzeichnisse oder Systemeinstellungen. Leider hat das Standardverfahren Schwächen:
- Geringe Granularität
- Discretionary Access Control
- Allmächtiger Root
Die Zugriffskontrolle von Linux kennt nur die Rechte Lesen, Schreiben und Ausführen, sie lassen sich zudem nur für den Besitzer einer Datei, die Mitglieder der Dateigruppe und alle anderen Benutzer getrennt festlegen. Für Root gelten keine Beschränkungen. Die Granularität dieser Rechte ist somit zu gering für viele Aufgaben.
Linux-Rechte: Ungenügend
Der Besitzer einer Datei hat die volle Verfügungsgewalt über sein Objekt (DAC, Discretionary Access Control). Kontrolliert ein Angreifer einen Prozess, dann gelten für seine Aktionen die Rechte des Benutzers, unter dessen Kennung der Prozess läuft. Der Angreifer kann so alle Dateien dieses Users beliebig manipulieren.
Der allmächtige Systemverwalter Root ist das gefährlichste der hier genannten Probleme. Viele Aktionen sind nur ihm vorbehalten, von Verwaltungsaufgaben bis zu einfachen Handlungen, etwa bestimmte Netzwerk-Ports öffnen. Folglich starten die meisten Serverdienste mit Root-Rechten und erhalten unbegrenzten Zugriff auf das gesamte System, ohne diese umfassenden Rechte zu benötigen. Es kommt noch schlimmer: Um später in beliebige Benutzerkennungen zu wechseln, müssen viele Dienste ständig als Root laufen oder diese Rechte jederzeit wiedererlangen können.
Die bereits seit längerem im Linux-Kernel eingeführten Posix-Capabilities erlauben es zwar einem von Root gestarteten Programm, auf einige Sonderrechte zu verzichten, das erfolgt aber freiwillig durch das Programm selbst.
Anforderungen an die Architektur
Das Hauptziel bei der Entwicklung von RSBAC war, ein flexibles und wirksames Zugriffskontrollsystem zu entwerfen, das die Linux-Mechanismen ergänzt. Um dies zu erreichen, muss das System einige Anforderungen erfüllen: Es soll als Rahmenwerk aufgebaut sein, das es dem Entwickler erlaubt, verschiedene Zugriffs-Entscheidungsmodelle einfach und schnell zu entwerfen und zu implementieren. Daraus ergibt sich eine klare Trennung zwischen entscheidenden Komponenten und solchen, die die Entscheidung durchsetzen. Die durchsetzenden Bestandteile sind unabhängig von denen, die Entscheidungen fällen. Neue Entscheidungsmodelle können die vorhandene Infrastruktur nutzen.
Es gibt inzwischen eine große Auswahl bewährter Sicherheitsmodelle für verschiedenste Aufgaben, je nach Situation sind auch Kombinationen dieser Modelle sinnvoll. Das Rahmenwerk soll deshalb mehrere Sicherheitsmodelle gleichzeitig und unabhängig voneinander unterstützen, sodass der Administrator für den jeweiligen Einsatzbereich die am besten geeigneten Modelle auswählen kann. Unabhängig vom Modell ist es nötig, jede Aktion und jede getroffene Entscheidung zu protokollieren. Dieses Logging muss vor Manipulationen geschützt sein.
Bereits das erste Design des RSBAC-Systems erfüllte fast alle Anforderungen. Im Laufe der letzten fünf Jahre ist die Menge an Funktionen und überwachten Objekten stark gewachsen, auch Netzwerkzugriffe unterliegen inzwischen der RSBAC-Kontrolle. Die Grundzüge des Designs haben sich dabei bewährt und blieben unverändert.
| Whitepaper |
|
The Role of Open Source in Data Integration
Obwohl in den letzten Jahren viele technische Fortschritte erzielt werden konnten, verfügen die meisten Datenintegrationsprozesse nach wie vor nur über eine sehr begrenzte Automatisierung. Das vorliegende White Paper von dem Industry Analyst Mark Madson wird zunächst ein grundlegendes Verständnis von Daten Integration vermitteln, die Vorzüge von Open Source Lösungen für Daten Integration erläutern und Ihnen professionelle Empfehlungen geben, damit Sie Ihre Integrationsjobs noch einfacher und produktiver gestalten können.
Download PDF (Registrierung erforderlich)
|
|
Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele (Folge 2)
Der zweite Teil des Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele White Papers beleuchtet anhand weiterer ausgewählter Case Studies die Implementierung von Open Source Datenintegration in der Praxis und benennt die daraus resultierenden Vorteile.
Download PDF (Registrierung erforderlich)
|
Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links"
nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedrucken Fassung entsprechen.
|