Komposition von. von SELinux-Sicherheitspolitiken

Transkript

1 Komposition von SELinux-Sicherheitspolitiken Anja Fischer Winfried E. Kühnhauser Technische Universität Ilmenau [a.fischer Zusammenfassung Moderne Systemplattformen wie TrustedBSD, Security Enhanced Linux (SELinux) oder Oracle Solaris sind mit Sicherheitsarchitekturen ausgestattet, die die dynamische Integration anwendungsspezifischer Sicherheitspolitiken ermöglichen. Sicherheitspolitiken stellen in diesen Systemen in analoger Weise zu Prozessen oder Dateien eine Basisabstraktion dar, die es ermöglicht, sämtliche Aktionen eines Systems diskreten oder obligatorischen Sicherheitsregeln zu unterstellen. Hiermit wird es nun möglich, in jedes IT-System sowohl auf die installierten Anwendungssysteme als auch auf die globale Sicherheitspolitik eines Unternehmens individuell abgestimmte Sicherheitspolitiken zu integrieren, die präzise Regeln zum Umgang mit sensitiven Informationen enthalten. Auf Grund der komplexen Problemstellung sind allerdings Erstellung und Management anwendungsspezifischer Sicherheitspolitiken mit einigem Aufwand verbunden ein zentraler Grund dafür, dass die Anwendung der vorhandenen Technologie heute noch kein Standard ist. Dieses Papier stellt eine Lösung für ein zentrales Problem im Management der Sicherheitspolitiken SELinux basierter IT-Systeme vor: der Erweiterung von Sicherheitspolitiken durch Fremdkomponenten. Schlüsselworte: Zugriffsschutzsysteme, Sicherheitspolitiken, Politikkomposition, SELinux, Management von SELinux-Sicherheitspolitiken 1 Einführung Zugriffsschutzsysteme heutiger IT-Systeme basieren auf Zugriffssteuerungsmechanismen, die konkrete Formen der Realisierung Lampson scher Zugriffsmatrizen [Lam74] darstellen. Sie wurden Mitte der 60er Jahre im vergangenen Jahrhundert entwickelt, um die damals aufkommenden Mehrbenutzer-Systeme mit elementaren Kontrollmechanismen für die gemeinsame Nutzung von Dokumenten zu versehen [Org72, Sal74]. Seit über 40 Jahren bilden diese Mechanismen in unveränderter Spezifikation und sogar in nahezu unveränderter Implementierung die Grundlagen der Zugriffssteuerung in Standard- Betriebssystemen der Unix- und Windows-Familien. Über vier Jahrzehnte hinweg hat das Vertrauen in diese Mechanismen allerdings auch dazu geführt, dass heute eine Last auf ihren Schultern ruht, für die sie niemals konzipiert waren; gezielte Angriffe auf IT-Systeme durch Organisationen, deren Geschäftsmodell auf der Nutzung von Verwundbarkeiten gründet, lagen nicht im Blick der damaligen Entwickler. So kann es auch nicht verwundern, dass Ursachen für die Die Arbeit wurde unterstützt durch die Carl-Zeiss-Stiftung D A CH Security 2010 syssec (2010) 1-??? (generiert am 30. Juni 2010).

2 2 Komposition von SELinux-Sicherheitspolitiken Verwundbarkeit heutiger IT-Systeme tief im Design der elementaren Sicherheitsmechanismen verwurzelt sind; solange dies so bleibt, werden ressourcenintensive und auf Grund ihrer grundsätzlichen Methodik unverlässliche Hilfsmittel wie Intrusion-Detection-Systeme, Firewalls, Virenscanner und Malware-Suchheuristiken notwendig sein. Dass es auch anders geht, zeigen Resultate von Projekten, die bei den tiefen Ursachen des Problems ansetzen und Betriebssysteme mit grundsätzlich neuen Sicherheitsarchitekturen entwickeln [LS01b, WFMV03, HLA + 05, ZBWM08, EK08]. Obwohl die Entwicklung dieser Systeme teils von Organisationen mit erheblichem Einfluss massiv unterstützt wird 1, ist ihr professioneller Einsatz heute immer noch kein Standard. Eine der Ursachen hierfür liegt in den neuen und teils komplexen Konzepten, mittels derer die Sicherheitseigenschaften dieser Systeme hergestellt werden. Eine zentrale Rolle spielen hier Sicherheitspolitiken [LS01a, WFMV03, WYA + 07, EK08], deren Modellierung, Spezifikation und Implementierung einerseits die Grundlage sämtlicher Sicherheitseigenschaften bilden, andererseits leider aber auch hochgradig komplex sind. Während also auf der einen Seite neue Konzepte die Tür zu signifikanten Fortschritten bei den Sicherheitseigenschaften von Systemplattformen öffnen, erfordern Spezifikation, Implementierung und Administration von Sicherheitspolitiken große Sorgfalt und anspruchsvolles Fachwissen. Insbesondere bei Systemen, deren Anwendungssoftware regelmäßig aktualisiert oder ergänzt wird, erzeugt dieses Konzept hohe Kosten: jede Veränderung der Anwendungssoftware erfordert eine Anpassung der Sicherheitspolitiken, die dazu neu modelliert und verifiziert werden müssen Aufgaben, die weit über die typischen Kompetenzbereiche heutiger Systemadministration hinaus gehen. Hersteller von Anwendungssystemen haben inzwischen auf dieses Problem reagiert und liefern ihre Software oft schon gemeinsam mit einer zugehörigen Sicherheitspolitikkomponente aus, die dann in eine bereits beim Anwender vorhandene Sicherheitspolitik integriert werden kann. Der Anwender ist nun aber in einer problematischen Situation: er muss entscheiden, ob die mitgelieferte Politikkomponente verträglich ist mit der Sicherheitspolitik seiner eigenen IT-Systeme. Wesentliche Fragestellungen sind hierbei, ob durch Integration der neuen Politikkomponente neue Rechte innerhalb des Zuständigkeitsraums der vorhandenen Politik entstehen, oder aber ob durch die neue Politikkomponente Rechte entstehen, die zu einer wechselseitigen Beeinflussung der Zuständigkeitsräume der neuen und alten Politikkomponenten führen. Diese Fragestellungen lassen sich auf eine Problemklasse zurückführen, die sich mit der Ausbreitung von Rechten in Zugriffssteuerungssystemen befasst. Dies eröffnet nun die Chance, existierende Modellanalysemethoden anzuwenden, Werkzeuge zur Automatisierung solcher Analysen einzusetzen, hiermit dann Aussagen über die wechselseitige Beeinflussung von alten und neuen Sicherheitspolitikkomponenten zu gewinnen und so auf ökonomische Weise eine verlässliche Entscheidungsgrundlage für die Akzeptierbarkeit neuer Politikkomponenten zu erhalten. In diesem Papier wird die Anwendung dieser Technik im Kontext von SELinux-Systemen und ihren Sicherheitspolitiken beschrieben. 1 US National Security Agency, Microsoft, Sun Microsystems

3 Komposition von SELinux-Sicherheitspolitiken 3 2 SELinux Ursache der inhärenten Schwächen Unix-artiger Zugriffssteuerungssysteme ist die Anwendung von für die Einsatzbereiche heutiger IT-Systeme überholten Konzepten wie diskrete Zugriffssteuerung (Discretionary Access Control, DAC) und omnipotente Administratoren. Diese Schwächen führen zu Verwundbarkeiten der IT-Systeme, denen nur durch fundamentale Neugestaltung der Zugriffssteuerungssysteme wirksam begegnet werden kann. Dieses Kapitel zeigt wesentliche Schwächen der Zugriffssteuerung Unix-artiger Systeme auf und diskutiert Konzepte der SELinux-Zugriffssteuerung zu ihrer Beseitigung. 2.1 Schwächen der Unix-Zugriffssteuerung Unix-artige Zugriffssteuerungssysteme basieren auf diskreter Zugriffssteuerung, bei der jeder Benutzer als Objektbesitzer die Zugriffsrechte seiner Objekte im eigenen Ermessen festlegen kann. Dies führt dazu, dass ein erheblicher Teil der Last der Verwaltung und Durchsetzung der systemweiten, organisationsspezifischen Sicherheitspolitik auf den Schultern jedes einzelnen Benutzers liegt. Auf der anderen Seite hat jeder einzelne Benutzer nur eine eingeschränkte Sicht auf die systemweite Rechtesituation, so dass er die Auswirkungen seiner Entscheidungen nicht vollständig erkennen kann und somit schon konzeptionell gar nicht in der Lage ist, seiner Verantwortung gerecht zu werden. Die Konsequenz sind oftmals verdeckte Informationsflüsse, welche die systemweite Sicherheitspolitik ohne weiteres unterlaufen können und in realen Systemen tatsächlich auch nachweisbar sind [AFK09]. Die Zugriffssteuerung findet auf der Ebene des Dateisystems statt, das jedem Objekt des Systems (Dateien, Verzeichnisse etc.) eine Menge von Rechten (read/write/execute) in Form von Zugriffssteuerungslisten assoziiert. Diese Zugriffsrechte beschreiben, in welcher Weise ein Benutzer (als Besitzer, als Mitglied einer Benutzergruppe oder generell als Benutzer eines Systems) unmittelbar Zugriff auf ein Objekt besitzt. Da jeder durch einen Benutzer gestartete Prozess sämtliche Rechte des Benutzers erbt, kann der Prozess auf alle Objekte zugreifen, auf die der Benutzer Zugriff hat, und kann insbesondere auch die Zugriffsrechte des Benutzers auf seine Objekte ändern. Fehlerhafte oder gar bösartige Programme sind damit in der Lage, die Sicherheitsmechanismen des Systems oder einzelner Applikationen zu umgehen oder zu manipulieren. Typischerweise werden zwei Benutzerkategorien unterschieden: Administratoren (Superuser/Root-Benutzer) und normale Benutzer. Administratoren zeichnen sich dadurch aus, dass sie per Definition vertrauenswürdig und somit berechtigt sind, auf alle Objekte unabhängig von Zugriffssteuerungslisten zuzugreifen. Oftmals benötigen Systemprogramme besondere Privilegien; die mangelhafte Feinkörnigkeit der Rechtesteuerung zwingt dann dazu, diese Programme mit der vollständigen Menge der Administratorrechte auszuführen. Auf diese Weise erhalten Systemprogramme wesentlich mehr Rechte als sie tatsächlich benötigen eine Schwachstelle, deren Ausnutzung seit langem zum Basisrepertoire von Schadsoftware gehört. Insgesamt führen diese Eigenschaften zu einer sehr grobgranularen Zugriffssteuerung. Darüber hinaus werden durch die grobgranularen Vererbungskonzepte Unix-artiger Systeme stets sämtliche Rechte des Aufrufers uneingeschränkt vererbt, so dass sich Rechte schnell und ohne Eingrenzung verbreiten können. Dies hat zur Folge, dass zum einen verdeckte Informationsflüsse die systemweite Sicherheitspolitik unterlaufen können. Zum anderen wird es Schadsoftware

4 4 Komposition von SELinux-Sicherheitspolitiken einfach gemacht, die Sicherheit des gesamten Systems durch Manipulieren oder Umgehen des vorhandenen Zugriffssteuerungssystems massiv zu beeinträchtigen. 2.2 Zugriffssteuerung in SELinux SELinux adressiert die in Abschnitt 2.1 vorgestellten Schwächen durch Integration einer obligatorischen Zugriffssteuerung (Mandatory Access Control, MAC) in den Linux Kernel, bei der die Spezifikation der systemweiten, organisationsspezifischen Sicherheitspolitik durch eine zentrale, kompetente Instanz und nicht durch einzelne Benutzer erfolgt. Realisiert wird dies auf Basis der Flask Sicherheitsarchitektur [SSL + 99] eine Sicherheitsarchitektur speziell für obligatorische Zugriffssteuerung, die sich durch striktes Trennen von Politikentscheidung und Politikdurchsetzung auszeichnet. Politikentscheidungen werden durch den zentralen Security Server getroffen; die Durchsetzung dieser Entscheidungen erfolgt durch sogenannte Object Manager. In der SELinux-Implementierung unterstützt der Security Server identitätsund rollenbasierte Zugriffssteuerung mit integriertem Typsystem (Type Enforcement). Konsequenz ist ein feingranulares Zugriffssteuerungssystem, das in wohldefinierte, abgegrenzte Bereiche/Sicherheitsdomänen unterteilt ist und in dem einzelne Benutzer nicht die Hoheit über Rechte und Sicherheitsdomänen haben. Damit ist das Vererben von Rechten von vornherein eingeschränkt, so dass sich Rechte nicht ohne Eingrenzung verbreiten können. Eine SELinux-Zugriffssteuerungspolitik ist eine Menge von Regeln, die auf vier elementaren Konstrukten basiert: Entitäten, Klassen, Typen und Rechte. Unter Entitäten werden individuelle Instanzen klassischer Abstraktionen eines Betriebssystems wie beispielsweise Prozesse (die stellvertretend für menschliche Benutzer agieren), Dateien, Verzeichnisse und Sockets verstanden. Jede Entität besitzt genau eine Klasse, welche die Entitäten entsprechend ihrer Betriebssystemabstraktionen beschreibt, z.b. die Klassen process, file, dir oder socket. Zusätzlich werden den Entitäten Typen zugeordnet; Zugriffsrechte der Entitäten werden ausschließlich über diese Typen definiert und nicht direkt über die Entitäten. Im Ergebnis enthält eine SELinux-Sicherheitspolitik Regeln zur Definition von Typen, die Zuordnung der Entitäten zu Klassen und Typen, sowie eine Menge von Zugriffsregeln. Folgendes Beispiel zeigt eine Zugriffsregel aus einer SELinux-Sicherheitspolitik; sie erlaubt Entitäten mit dem Typ passwd_t einen Lese/Schreibzugriff auf Entitäten der Klasse file mit dem Typ shadow_t. allow passwd_t shadow_t:file {read write}; Eine mittels solcher Regeln spezifizierte Zugriffssteuerungspolitik befindet sich in den textbasierten Konfigurationsdateien von SELinux und kann nur durch eine kompetente Instanz modifiziert werden. Für die Durchsetzung der spezifizierten Sicherheitspolitik werden die Konfigurationsdateien dann in eine binäre Repräsentation kompiliert und in den SELinux Security Server geladen. Dieser ist nun in der Lage, Zugriffsentscheidungen basierend auf der spezifizierten Sicherheitspolitik zu treffen. SELinux-Sicherheitspolitiken erlauben auf diese Weise eine sehr feingranulare Spezifikation und Durchsetzung von Zugriffssteuerungsregeln und sind eine scharfe Waffe gegen die in Abschnitt 2.1 diskutierten grundsätzlichen Schwächen herkömmlicher Zugriffssteuerungssysteme. Auf der anderen Seite ist die Erstellung einer SELinux-Sicherheitspolitik ein komplexer Prozess, der große Sorgfalt und erhebliches Fachwissen erfordert; eine Beispielpolitik für Linux

5 Komposition von SELinux-Sicherheitspolitiken besteht aus mehr als Politikregeln [JSZ03], wobei die Zusammenhänge zwischen den einzelnen Regeln erst die eigentliche Komplexität ausmachen. Dies ist eine Aufgabe, die weit über den typischen Aufgabenbereich von Systemadministratoren hinausgeht und mindestens das Kompetenzniveau eines Anwendungsentwicklers erfordert. 3 Komposition von SELinux-Sicherheitspolitiken Bei der Installation einer neuen Applikation muss nun die vorhandene Sicherheitspolitik ergänzt werden, da die neue Applikation ansonsten über keinerlei Rechte verfügen würde. Dazu ist es nötig, dass die neue anwendungsspezifische Sicherheitspolitik ebenfalls als SELinux- Regelmenge vorliegt (oftmals durch die Hersteller zur Verfügung gestellt). Diese wird dann zu der bereits bestehenden Sicherheitspolitik in den Konfigurationsdateien hinzugefügt; die Dateien werden neu kompiliert und das Binärformat in den Security Server geladen. Bevor jedoch ein Anwender die neue Sicherheitspolitik integriert, muss er entscheiden, ob diese verträglich mit seiner vorhanden Sicherheitspolitik ist. Von grundsätzlicher Bedeutung für die Verträglichkeit ist hierbei insbesondere, ob durch Integration der neuen Politikkomponente neue Rechte innerhalb des Zuständigkeitsraums der vorhandenen Politik entstehen durch die vorhandene Politik Rechte innerhalb des Zuständigkeitsraums der neuen Politikkomponente ermöglicht werden durch die neue Politikkomponente Rechte entstehen, die zu einer wechselseitigen Beeinflussung der Zuständigkeitsräume der neuen und alten Politikkomponenten führen. Diese Fragestellungen lassen sich auf eine allgemeinere Problemklasse zurückführen, die sich mit der Ausbreitung von Rechten in Zugriffssteuerungssystemen befasst eine Problemklasse, deren Komplexität oft an die Grenzen des überhaupt Berechenbaren stößt [HR78] und deren Beantwortung massiver Unterstützung automatischer Analysewerkzeuge bedarf. 3.1 Die Idee Die Untersuchung von Rechteausbreitungen in Zugriffssteuerungssystemen ist das primäre Ziel von HRU-Sicherheitsmodellen [HRU76]. Idee ist es nun, bei der Analyse der Wechselwirkungen zwischen SELinux-Sicherheitspolitiken auf den analytischen Möglichkeiten der HRU- Modellen aufzubauen und eine Methode zu entwickeln, mittels der die existierenden Techniken und Werkzeuge der HRU-Modellanalyse nutzbar werden. Diese Methode besteht aus drei Schritten der Transformation der zu komponierenden SELinux-Sicherheitspolitiken in ihre HRU-Modelle, der Analyse der Wechselwirkungen dieser Modelle (ihre Abgeschlossenheitseigenschaften, s.u.) und der Analyse von Rechteausbreitungen. Im ersten Schritt erfolgt eine Reformulierung der SELinux-Politiken als HRU-Modelle. Ein automatisches Werkzeug übersetzt dazu die Politiken aus ihrer Standard-Darstellung [Sma03] in ein HRU-Modell (Abschnitt 3.3). Anschließend werden die hierbei entstandenen Modelle auf ihre Abgeschlossenheitseigenschaften untersucht (Abschnitt 3.4). Dabei entsteht entweder das Ergebnis, dass keinerlei Wechselwirkungen bestehen und alte und neue Politikkomponente sich gegenseitig nicht beeinflussen ein eher seltener Fall, da i.a. Wechselwirkungen bereits auf Grund gemeinsam genutzter Systemkomponenten wie dem z.b. dem Dateisystem oder einem

6 6 Komposition von SELinux-Sicherheitspolitiken DBMS zu erwarten sind oder aber es werden Überlappungsbereiche identifiziert, die dann im dritten Schritt zum Gegenstand detaillierter Untersuchung werden (Abschnitt 3.5). Durchgängig werden in allen Schritten Werkzeuge der Security Engineering Workbench I- Graphoscope [Amt08] eingesetzt. I-Graphoscope ist ein Softwaresystem zur analytischen, simulativen und visuellen Analyse von Zugriffssteuerungssystemen und wurde in einigen seiner Grundfunktionen in [AFK09] vorgestellt. 3.2 HRU-Sicherheitsmodelle Ein HRU-Sicherheitsmodell ist ein Zustandsautomat (Q, Σ,δ,q 0 ) mit einem Zustandsraum Q, einem Eingabealphabet Σ, einer Zustandsübergangsfunktion δ und einem Anfangszustand q 0. Jeder Zustand q Q beschreibt eine Momentaufnahme der Zugriffsrechte eines IT-Systems, wobei Q = 2 S 2 O M ist mit S als Menge aller Subjekte (Benutzer, ihre Prozesse), O als Menge aller Objekte (Dateien, Verzeichnisse, Sockets, Pipes etc.) und M = {m m : S O 2 R } als Menge aller Zugriffsmatrizen, deren Zellen Teilmengen einer endlichen Rechtemenge R enthalten. Jeder Modellzustand q reflektiert somit die vollständige Rechtesituation der Zugriffssteuerung eines IT-Systems zu einem konkreten Zeitpunkt. Durch Definition der Zustandsübergangsfunktion δ und Beobachtung der Zustandsübergänge des Automaten können nun Sicherheitseigenschaften eines Systems analysiert werden; insbesondere lassen sich Aussagen über Rechteausbreitungen durch Zustandserreichbarkeitsanalysen treffen. Die Analyse mittels HRU-Modellen konzentriert sich dabei auf eine Familie sehr fundamentaler Fragestellungen: wenn ein bestimmter Zustand (eine konkrete Rechtesituation) gegeben ist, ist es dann möglich, dass ein bestimmtes Subjekt irgendwann in der Zukunft ein bestimmtes Recht bzgl. eines bestimmten Objekts erhält? Oder, mit anderen Worten, gegeben ein Zustand q, ist es möglich, dass in einem zukünftigen Zustand q = δ (q,a), a Σ, ein bestimmtes Recht r in einer Matrixzelle auftaucht? Wenn dies geschehen kann, gelten solche Zustände als nicht HRU-safe bzgl. r. Präzise gesagt, bei gegebenem Recht r heißt ein Zustand q eines HRU-Modells HRU-safe bzgl. r genau dann wenn s S,o O,a Σ : r / m(s,o) r / m (s,o) mit q = δ (q,a) [HRU76]. Wenn also ein gegebener Zustand HRU-safe bzgl. eines Rechtes ist, so ist garantiert, dass dieses Rechte niemals an neuen Stellen auftauchen, d.h. sich ausbreiten kann. 3.3 Transformation von SELinux-Politiken Eine SELinux-Sicherheitspolitik kann durch drei kooperierende Abbildungen beschrieben werden: - cl : E C (Klassenzuordnung) { E 2 - type : T, e E und cl(e) = process E T, e E und cl(e) process (Typzuordnung) - te : T T 2 R (Type Enforcement) Die Zuordnung einer Klasse zu einer Entität ist statisch und ändert sich während des Lebenszyklus einer Entität nicht. Sie wird durch die Abbildung cl beschrieben, welche die Menge der Entitäten E auf die Menge der Klassen C abbildet. Die Typisierungsfunktion type beschreibt

7 Komposition von SELinux-Sicherheitspolitiken 7 die Zuweisung der Typen T zu Entitäten. Entitäten der Klasse process können zu einem Zeitpunkt eine Menge von Typen besitzen; Entitäten aller anderen Klassen verfügen zu einem Zeitpunkt genau über einen Typ. Da sich Typzuweisungen z.b. bei Typtransitionen (type transitions) ändern können, ist die Typisierungsfunktion dynamisch. Die Definition von Zugriffsrechten erfolgt über Typen (und nicht Entitäten) mittels der te-matrix. Diese ordnet jedem Typpaar eine Teilmenge an Zugriffsrechten R zu wie z.b. te(passwd_t, shadow_t) = {read, write} (Beispiel aus Kapitel 2.2). Diese Zuordnung ist zur Laufzeit einer Sicherheitspolitik statisch und kann nur durch Neuladen der Sicherheitspolitik in den Security Server manipuliert werden. Mit Hilfe dieser Abbildungen lässt sich nun eine SELinux-Sicherheitspolitik in ein HRU- Modell transformieren. Abbildungen über endliche Mengen sind auch als Matrizen darstellbar, deren Integration in HRU-Modelle typischerweise durch Zweckentfremdung der Zugriffsmatrix erfolgt. Die Zugriffsmatrix m des Modells (der Zustand) ist politikabhängig und wird nun aus der Konkatenation der Funktionen cl, type und te gebildet. Abbildung 1 skizziert eine solche Zugriffsmatrix: die Matrixzeilen repräsentieren die Typen und Entitäten, die Matrixspalten stellen Typen und Klassen dar. Die Zellen enthalten dann Teilmenge der Rechtemenge oder die Zuordnung der Entitäten zu Klassen und Typen. Abbildung 1: Zustand einer SELinux-Sicherheitspolitik im HRU Kalkül. Die Zustandsübergangsfunktion eines solchen Modells ist unabhängig von einer spezifischen SELinux-Sicherheitspolitik. Zustandsübergänge bewirken Änderungen in der Zugriffsmatrix; da die Funktionen cl und te unveränderlich sind, betreffen Zustandsübergänge nur den Teil der Matrix, der die type-funktion realisiert. Sie können in zwei Fällen auftreten: Typtransitionen und Typänderungen (type change) von Entitäten. Im folgenden wird exemplarisch der Zustandsübergang für eine Typtransition eines Prozesses skizziert. Damit ein neuer Prozess erzeugt wird und dieser eine Typtransition vollziehen kann, müssen drei Bedingungen erfüllt sein: - Der Typ des aufrufenden Prozesses muss das Recht execute für den Typ einer Entität der Klasse file besitzen. - Der Typ des neu erstellten Prozesses muss das Recht entrypoint für den Typ der ausführbaren Datei besitzen. - Der Typ des neu erstellten Prozesses muss das Recht transition für den neuen Typ einer Entität der Klasse process besitzen.

8 8 Komposition von SELinux-Sicherheitspolitiken Die erste Bedingung ist nötig, damit die ausführbare Datei vom laufenden Prozess ausgeführt werden kann. Beim Ausführen der Datei wird ein neuer Prozess (eine Entität der Klasse process) erzeugt, der den gleichen Typ besitzt wie der aufrufende Prozess. Die zweite Bedingung stellt sicher, dass ein Eintrittspunkt in den neuen Typ über die ausgeführte Datei existiert. Anschließend überprüft die dritte Bedingung, dass die Transition zwischen altem und neuem Typ vollzogen werden darf. Nur wenn alle drei Bedingungen erfüllt sind, kann eine Typtransition und damit ein Zustandswechsel erfolgen. Dabei wird die type-funktion innerhalb der Matrix so angepasst, dass der neu erzeugte Prozess nicht mehr den Typ des aufrufenden Prozesses zugeordnet ist, sondern dem neuen Typ (aus Bedingung 3) zugewiesen wird. Analog dieser Überlegungen müssen die Bedingungen und Aktionen für jeden Zustandsübergang definiert werden. Auf diese Weise lässt sich jede SELinux-Sicherheitspolitik als HRU-Modell darstellen. Da die Zustandsübergangsfunktion politikunabhängig ist, muss lediglich der Zustand der Politik in die Zugriffsmatrix überführt werden. Die Zustandsübergangsfunktion ist für alle eine SELinux- Sicherheitspolitik repräsentierende HRU-Modelle identisch. 3.4 Kompositionstheoretischer Hintergrund Durch die Transformation von SELinux-Sicherheitspolitiken in ihre äquivalenten HRU-Modelle wird nun die in [FK10] vorgestellte Kompositionsalgebra anwendbar, mit deren Theoremen die Wechselwirkungen der komponierten Modelle präzise analysiert werden können. Für den interessierten Leser skizziert dieser Abschnitt als Konzentrat von [FK10] den formalen Hintergrund der Analysemethode; anschließend wird in Abschnitt 3.5 die Anwendung dieser Theorie auf die Praxis bei der Komposition von SELinux-Sicherheitspolitiken gezeigt, wobei dieser nachfolgende Abschnitt auch ohne detailliertes Studium der Theorie in 3.4 verständlich ist Abgeschlossenheit Gegeben sei ein HRU-Modell (Q, Σ,δ,q 0 ). Ein solches Modell wird als komponiert bezeichnet, wenn eine Dekompositionsfunktion d existiert, die den Zustandsraum Q = 2 S 2 O M des Modells in 2 oder mehrere Zustandsräume Q i von Teilmodellen (Q i, Σ,δ i,q 0 i ) zerlegt, wobei - Q i = 2 S i 2 O i M i,s i S,O i O,M i = {m m : S i O i 2 R } - δ i (q Q i,a) = δ(q,a) Q i für q Q und a Σ - q 0 i = q 0 Q i. Der Ausdruck q Q i bezeichnet dabei die Einschränkung eines Zustands q Q auf den kleineren Zustandsraum Q i eines Teilmodells. Präzise gesagt, q Q i = (S S i,o O i,m M i ) entfernt diejenigen Teile eines Zustands q, die nicht im Definitionsbereich des Teilmodells i liegen. Da aus den Safety-Eigenschaften der Teilmodelle die Eigenschaften des komponierten Modells abgeleitet werden sollen, müssen die Teilmodelle bestimmte Eigenschaften besitzen: jedes Teilmodell sollte ein autonomes HRU-Modell sein (eine plausible Annahme, da die Modelle unabhängig voneinander entwickelt wurden), und die Teilmodelle müssen gemeinsam exakt dasselbe Verhalten besitzen wie das komponierte Gesamtmodell. In den folgenden zwei Abschnitten werden Modellautonomie und Verhaltensäquivalenz näher betrachtet.

9 Komposition von SELinux-Sicherheitspolitiken Autonomie der Teilmodelle Damit ein Teilmodell ein autonomes HRU-Modell ist, muss sein Zustandsraum Q i abgeschlossen bezüglich seiner Zustandsübergangsfunktion δ i sein. Abgeschlossen bedeutet dabei, dass für jeden Zustand q des komponierten Modells gelten muss, dass bei Einschränkung von q auf den Zustandsraum Q i des Teilmodells jeder von q im komponierten Modell durch Anwendung von δ erreichbare Zustand ebenfalls in Q i liegt: Def. Abgeschlossenheit. Eine Teilmenge Q i Q eines HRU-Modells (Q, Σ,δ,q 0 ) heißt zustandsabgeschlossen genau dann wenn q Q,a Σ : q Q i δ(q,a) Q i Isomorphie komponierter Modelle Um nun Safety-Eigenschaften des komponierten Modells aus der Menge seiner Teilmodelle abzuleiten, muss jede Komposition sowohl die Struktur als auch das Verhalten der komponierten Teilmodelle bewahren; mit anderen Worten, die Dekompositionsfunktion d muss ein Isomorphismus sein. Um dies zu erreichen, muss d vier Eigenschaften besitzen: die Zustandsräume der Teilmodelle müssen jeweils zustandsabgeschlossen sein, die Modellkomposition muss eine vollständige Komposition der Zustandsräume der Teilmodelle sein, sie muss redundanzfrei sein, und das Verhalten des komponierten Gesamtmodells muss dem seiner Teilmodelle in deren individuellen Zustandsräumen entsprechen. Diese Eigenschaften sind in der folgenden Defintion zusammengefasst. Def. Modell/Teilmodellisomorphie. Für ein gegebenes HRU-Modell (Q, Σ,δ,q 0 ) heißt eine Funktion d,d(q) (Q 1,...,Q n ) Dekomposition genau dann, wenn die folgenden Bedingungen gelten (a) jedes Q i ist zustandsabgeschlossen (b) n i=1 Q i = Q (d.h. n i=1 (S i O i ) = (S O)) (Vollständigkeit) (c) i,j,i j : Q i Q j = (d.h. (S i O i ) (S j O j ) = ) (Redundanzfreiheit) (d) q Q,a Σ : δ i (q Q i,a) = δ(q,a) Q i (Verhaltensäquivalenz) mit Q i wie oben definiert. Intuitiv gesehen sind Teilmodelle autonome HRU-Modelle, die sich mit dem Gesamtmodell das Autorisierungsschema teilen, jedoch kleinere Zustandsräume besitzen. Dabei definieren die n Teilmodelle Q 1...Q n gemeinsam eine virtuelle Zustandsübergangsfunktion δ, δ : Q 1... Q n Σ (Q 1...Q n ), δ(q 1,...,q n,a) (δ 1 (q 1,a),...,δ n (q n,a)) mit δ i wie unter (d) definiert. Die Eigenschaften (b) und (c) implizieren nun die Existenz einer Dekompositionsfunktion d : Q Q 1... Q n, d(q) (q Q 1,...,q Q n ), die die partiellen Zustandsräume der Teilmodelle selektiert (Abb. 2).

10 10 Komposition von SELinux-Sicherheitspolitiken Auf Grund von (a), (b) und (c) ist d ein Homomorphismus von Q nach Q 1...Q n, und wegen (d) gilt d(δ(q,a)) = δ(d(q),a) (Abb. 3). Wegen (b) und (c) ist d bijektiv, und eine Umkehrabbildung d 1 : Q 1... Q n Q (Kompositionsabbildung) existiert, die die Ergebnisse der Zustandswechsel der Teilmodelle rekombiniert durch d 1 (q 1...q n ) n i=i q i. Daher ist d ein Isomorphismus, und δ(q,a) = d 1 (δ(d(q),a)) gilt, so dass die Isomorphie des komponierten Modells und der Menge seiner Teilmodelle folgt. Abbildung 2: Dekompositionsfunktion d Abbildung 3: Dekompositionsisomorphismus 3.5 Anwendung der Ergebnisse Dieses Papier diskutiert ein zentrales Problem im Sicherheitsmanagement SELinux basierter IT-Systeme, welches immer dann entsteht, wenn installierte Anwendungssoftware und damit die sie kontrollierenden Komponenten der SELinux-Sicherheitspolitik aktualisiert oder neue Anwendungssoftware installiert wird. In diesen Fällen wird der installierten Sicherheitspolitik eine neue Komponente hinzugefügt, wobei sowohl die Wirkung der neuen Komponente als auch die potenziell entstehenden Wechselwirkungen zwischen der neuen Komponente und der installierten Politik unbekannt sind und Anlass zu den eingangs dieses Kapitels genannten Fragestellungen geben. Die Beantwortung dieser Fragen erfolgt nun in drei Schritten. Im ersten Schritt werden sowohl die neue Politikkomponente als auch die vorhandene SELinux- Sicherheitspolitik in verhaltensäquivalente HRU-Sicherheitsmodelle transformiert (vgl. Abschnitt 3.3); diese Transformation erfolgt werkzeuggestützt vollständig automatisch. Im zweiten Schritt wird untersucht, ob sich für diese beiden HRU-Modelle ein Kompositionsisomorphismus finden lässt, der die Bedingungen (a)-(d) erfüllt. Ist dies der Fall, so sind beide Modelle abgeschlossen und wechselwirkungsfrei sind. Einserseits sind damit die eingangs genannten Fragestellungen beantwortet; darüber hinaus lassen sich als willkommenes Nebenresultat die Ergebnisse einer isolierten Safety-Analyse der neuen Politikkomponente auf die Safety-Eigenschaften der komponierten Gesamtpolitik übertragen. Der Regelfall dieses Schrittes dürfte allerdings das Ergebnis sein, dass die neue Politikkomponente mit der vorhandenen Politik Überlappungsbereiche besitzt; Bereiche also, für die sowohl

11 Komposition von SELinux-Sicherheitspolitiken 11 Regeln der vorhandenen Politik als auch Regeln der neuen Politikkomponente gelten. Derartige Bereiche entstehen dann, wenn die neue oder aktualisierte Anwendungssoftware mit anderen Anwendungssystemen gemeinsame Ressourcen nutzt (Dateisystem, DBMS etc.). In diesem Fall werden diese Überlappungsbereiche in diesem Schritt präzise identifiziert und so einer Einzelbetrachtung zugänglich, die teilweise automatisch erfolgen kann, teilweise aber auch menschlicher Abwägungen bedürfen. Zur Illustration wird noch einmal auf Abbildung 1 verwiesen. Gegeben sind also zwei HRU-Modelle, in deren Matrix m jeweils das SELinux Type Enforcement (te), die Typzuordnungsfunktion type sowie die Klassifikationsfunktion cl wie in Abschnitt 3.3 beschrieben integriert sind. Separat für die entsprechenden Teilmatrizen werden die Modelle nun sukzessive auf Konflikte bzgl. ihrer Klassifikationsfunktion, ihrer Typzuordnung und ihres Type Enforcements untersucht. Konflikte der Klassifikationsfunktionen Konflikte der Klassifikationsfunktionen liegen vor, wenn die beiden Politiken einer Entität verschiedene Klassen zuordnen, also beispielsweise der Entität /etc/inid.d in einer Politik die Klasse Datei, in der anderen Politik die Klasse Prozess zugeordnet ist. Konflikte der Klassifikationsfunktionen sind Politikunverträglichkeiten, die eine Politikkomposition grundsätzlich verhindern. Mit E n,e b als Bezeichnungen der Entitätenmengen der neuen bzw. bestehenden Politik sind Konflikte beschrieben durch e E n E b : cl n (e) cl b (e) und damit werkzeuggestützt und automatisch in den cl-matrizen auffindbar. Konflikte der Typzuordnungen Konflikte der Typzuordnungen liegen vor, wenn die beiden Politiken einer Entität verschiedene Typmengen zuordnen, also beispielsweise der Entität /etc/inid.d in einer Politik der Typ file_t und in der anderen Politik die Klasse user_t zugeordnet ist. Konflikte der Typzuordnungsfunktionen sind nicht notwendigerweise Politikunverträglichkeiten; vielmehr ist es durchaus denkbar, dass in der neuen Politikkomponente für eine Entität eine kleinere Typemenge ausreicht. In diesem Fall wird also differenziert: 1. e E n E b : type n (e) type b (e), d.h. die Entität kommt mit weniger Typen aus (und benötigt damit weniger Rechte) als ohnehin bereits in der bestehenden Politik vorhanden; dieser Fall ist unkritisch bei der Komposition 2. in allen anderen Fällen benötigt die Entität in der neuen Politkkomponente mehr Rechte als bereits in der bestehenden Politik vorhanden. An dieser Stelle wurde also eine Rechteausweitung gegenüber der vorhandenen Politik identifiziert und es muss geprüft werden, ob diese spezielle Rechteausweitung konform mit der organisationsspezifischen Sicherheitspolitik ist. Konflikte des Type Enforcements Konflikte beim Type Enforcement liegen vor, wenn die beiden Politiken in ihrer Type Enforcement Matrix in derselben Zelle unterschiedliche Rechtemengen besitzen. Auch hier gibt es den unkritischen Fall, dass die neue Politikkomponente dort weniger Rechte erfordert als bereits in der bestehenden Politik vorhanden sind, d.h. es gilt (t,u) (T n T n ) (T b T b ) : m n (t,u) m b (t,u); in allen anderen Fällen bestehen für das Typpaar in der neuen Politikkomponente mehr Rechte als bereits in der bestehenden Politik vorhanden. An dieser Stelle wurde

12 12 Komposition von SELinux-Sicherheitspolitiken also ebenfalls eine Rechteausweitung gegenüber der vorhandenen Politik identifiziert und eine Prüfung auf Konformität mit der organisationsspezifischen Sicherheitspolitik muss erfolgen. Automatisierung der Konfliktanalyse Die formalen Grundlagen des Verfahrens lassen eine weitgehende Unterstützung der Analyse durch automatische Werkzeuge zu. Die Integration geeigneter Analysealgorithmen erfolgt derzeit in das Security Engineering Framework I-Graphoscope [Amt08]. 4 Zusammenfassung In Sicherheitspolitik kontrollierten Systemumgebungen tritt bei Aktualisierung oder Neuinstallation von Anwendungssoftware das Problem der Integration von Fremdkomponenten in die Sicherheitspolitik auf; dies birgt die Gefahr der Verletzung der Integrität der Sicherheitspolitik oder die Gefahr unbekannter Wechselwirkungen zwischen Politik und Fremdkomponente. In diesem Papier wird die Integration neuer Komponenten in eine Sicherheitspolitik auf das allgemeinere Problem ihrer Koexistenz und Kooperation zurückgeführt. Eine Formalisierung dieses Problems mittels isomorpher Komposition von HRU-Modellen schafft die Voraussetzung für eine automatische Analyse, an deren Ende eine präzise Identifikation der Wechselwirkungen von Sicherheitspolitiken steht. Das entwickelte Verfahren wurde am Beispiel der Erweiterung von SELinux-Sicherheitspolitiken illustriert. An der Professionalisierung der Werkzeugunterstützung wird derzeit gearbeitet. Literatur [AFK09] Peter Amthor, Anja Fischer, and Winfried E. Kühnhauser. Analyse von Zugriffssteuerungssystemen. In Patrick Horster, editor, Proceedings of the 2009 D A CH Security Conference, pages syssec Verlag, [Amt08] Peter Amthor. Generierung von Informationsflussgraphen aus HRU-Modellen. Studienarbeit, Technische Universität Ilmenau, October [EK08] [FK10] [HLA + 05] [HR78] Petros Efstathopoulos and Eddie Kohler. Manageable Fine-Grained Information Flow. In Proc EuroSys Conference, pages ACM SIGOPS, April Anja Fischer and Winfried E. Kühnhauser. Efficient Algorithmic Safety Analysis of HRU Security Models. In International Conference on Security and Cryptography (SECRYPT 2010), To appear. Galen Hunt, James Larus, Martin Abadi, Mark Aiken, Paul Barham, Manuel Fähndrich, Chris Hawblitzel, Orion Hodson, Steven Levi, Nick Murphy, Bjarne Steendgaard, David Tarditi, Ted Wobber, and Brian Zill. An Overview of the Singularity Project. Technical Report MSR-TR , Microsoft Research, Michael A. Harrison and Walter L. Ruzzo. Monotonic Protection Systems. In R. DeMillo, D. Dobkin, A. Jones, and R. Lipton, editors, Foundations of Secure Computation, pages Academic Press, 1978.

13 Komposition von SELinux-Sicherheitspolitiken 13 [HRU76] [JSZ03] [Lam74] [LS01a] [LS01b] [Org72] [Sal74] Michael A. Harrison, Walter L. Ruzzo, and Jeffrey D. Ullman. Protection in Operating Systems. Communications of the ACM, 19(8): , August Trent Jaeger, Reiner Sailer, and Xiaolan Zhang. Analyzing Integrity Protection in the SELinux Example Policy. In Proc. 12th USENIX Security Symposium, pages USENIX Association, Butler W. Lampson. Protection. Operating Systems Review, 8(1):18 24, January Peter A. Loscocco and Stephen D. Smalley. Integrating Flexible Support for Security Policies into the Linux Operating System. In Clem Cole, editor, Proc USENIX Annual Technical Conference, pages 29 42, Peter A. Loscocco and Stephen D. Smalley. Meeting Critical Security Objectives with Security-Enhanced Linux. In Proceedings of the 2001 Ottawa Linux Symposium, Elliott I. Organick. The Multics System: An Examination of its Structure. MIT Press, Cambridge, MA, USA, Jerome H. Saltzer. Protection and the Control of Information Sharing in Multics. Communications of the ACM, 17(7): , July [Sma03] Stephen D. Smalley. Configuring the SELinux Policy. Technical Report , NAI Labs, January [SSL + 99] Ray Spencer, Stephen Smalley, Peter Loscocco, Mike Hibler, David Andersen, and Jay Lepreau. The Flask Security Architecture: System Support for Diverse Security Policies. In Proc. 8th USENIX Security Symposium, [WFMV03] Robert Watson, Brian Feldman, Adam Migus, and Chris Vance. Design and Implementation of the TrustedBSD MAC Framework. DARPA Information Survivability Conference and Exposition, 1:38, [WYA + 07] Ted Wobber, Aydan Yumerefendi, Martin Abadi, Andrew Birrell, and Daniel R. Simon. Authorizing Applications in Singularity. In Proc. of the 2007 EuroSys Conference, pages ACM SIGOPS, March [ZBWM08] Nickolai Zeldovich, Silas Boyd-Wickizer, and David Mazières. Securing Distributed Systems with Information Flow Control. In NSDI 08: Proceedings of the 5th USENIX Symposium on Networked Systems Design and Implementation, pages , Berkeley, CA, USA, USENIX Association.