Eine ausgefeilte Zugriffskontrolle ist die Basis eines sicheren Linux. Die National Security Agency (NSA) entwickelt mit SE Linux ein komplexes System unter der GPL, in dem der Admin die Rechte exakt regelt. Dieser Beitrag erläutert Hintergründe, Grundlagen, Installation und Praxis.
Sie ist eine Quelle zahlreicher Mythen: Gerüchte kursieren über Mathematiker und Computer, die jeden Code knacken. IT-Sicherheit eine Legende? Die National Security Agency (NSA) sieht das anders und kümmert sich um mehr Sicherheit. Ein Ergebnis ist Security Enhanced Linux (SE Linux), das als Forschungsprototyp entstand[1]. SE Linux ergänzt Linux um zusätzliche Zugriffskontrollen. Es entscheidet anhand einer Regelbasis (Policy), wer auf welche Systemteile welchen Zugang hat, also welcher Prozess unter welcher Benutzerkennung welche Dateien öffnen oder welche Netzverbindung aufbauen darf.
Die Policy lässt sich von normalen Systembenutzern nicht beeinflussen, sie wird vom Admin vorgegeben - damit setzt SE Linux MAC um (Mandatory Access Control, siehe Kasten "Wichtige Begriffe"). Dass die Sicherheitseinstellungen sehr detailliert möglich sind, hat seinen Preis in der beachtlichen Komplexität. Um ein Programm auf SE Linux geschützt laufen zu lassen, muss der Admin jede Datei kennen, die der Prozess öffnet, und auch jedes Unterprogramm, das er aufruft. Der Aufwand lohnt sich aber durch den Schutz, den der Admin damit erreicht.
Die Sicherheitskonzepte von SE Linux wurden ursprünglich nicht für Linux entworfen. Die NSA entwickelte zusammen mit der Firma Secure Computing[13] (bekannt durch das TIS Firewall Toolkit) zunächst zwei Architektur-Prototypen für den Mach-Kernel[14]: DT Mach (Distributed Trusted Mach) und DTOS (Distributed Trusted Operating System). Erst die Weiterentwicklung Flask (Flux Advanced Security Kernel) wurde dann auf Linux portiert.
Aufgabe des Flask-Systems ist es, die Integrität und Vertraulichkeit der Informationen sicherzustellen. Mit anderen Worten: Es geht um Zugriffskontrolle. Während ein Standard-Linux-Kernel oft die einfache Antwort gibt "Root darf immer, der Rest nie", bietet Flask feiner abgestufte Sicherheitsvorgaben. Diese Vorgaben betreffen die Zugriffsrechte auf Dateien, aber auch die Kommunikation zwischen Prozessen und vieles mehr. Wie andere Pakete auch kann SE Linux nur bedingt protokoll- oder programmspezifische Schwächen ausgleichen, es dämmt aber ihre Auswirkung ein.
Die zentrale Komponente der Flask-Architektur ist der Security-Server. Er trifft alle sicherheitsrelevanten Entscheidungen. Der Name stammt noch von den ersten Mach-Implementierungen, bei denen war es tatsächlich ein Userspace-Prozess. Unter Linux ist dieser Server ein Kernel-Subsystem.
Die zweite Komponente sind Objektmanager. Sie verwalten die Sicherheitsattribute, sorgen für korrekte Zuordnung zu den Objekten (Dateien, Prozesse, Sockets ...) und setzen die Entscheidung des Security-Servers um. Bei den Objektmanagern handelt es sich um die bekannten Kernel-Subsysteme wie Prozessmanager, Filesysteme oder Sockets, die entsprechend erweitert wurden.
Als Basis für die Entscheidungen des Security-Servers dienen so genannte Security Contexts, sie fassen verschiedene Sicherheitsattribute zusammen. Ein Context bestehen aus der Benutzeridentität, seiner Rolle, einem Typ und optional noch einem MLS-Level (Multi Level Security). Dabei sind nur legale, dem Security-Server bekannte Kombinationen zugelassen.
Die einzelnen Komponenten eines Security Contexts stammen von den Abstraktionsebenen, die SE Linux einführt. Durch diese Ebenen wird es einfacher, die komplexe Realität der möglichen Zugriffe zu beherrschen. Die Zugriffskontrolle muss für jedes Programm regeln, unter welchen Voraussetzungen es Zugang zu welchen Objekten erhält.
Die erste Abstraktion sind Benutzer. Die Benutzerverwaltung von SE Linux ist aber unabhängig von der User-ID in Linux. Das hat mehrere Vorteile, beispielsweise lässt sich die SE-Linux-Benutzeridentität nach einem Login nicht mehr ändern. Der Wechsel von Berechtigungen gelingt über das Ändern der Rolle (ein weiteres Sicherheitsattribut) oder des Typs (das dritte Attribut).
Mehrere Linux-Benutzer lassen sich zu einem unprivilegierten SE-Linux-Benutzer zusammenzufassen, die Menge und Komplexität der Regeln bleibt dadurch überschaubar. Ein Beispiel ist der generische SE-Linux-User »user_u«. Nur für Benutzer, die mehr als die Standardrechte des »user_u«-Benutzers benötigen, ist die Policy anzupassen.
Bei SE Linux bezieht sich der Begriff Benutzer in der Regel auf reale Personen, die interaktiv Zugang zum System haben, Ausnahme ist »system_u«. Zusätzliche Pseudo-User für bestimmte Prozesse sind aber nicht mehr erforderlich, die Rechte dieser Prozesse sind durch den jeweiligen Typ festgelegt. Dennoch werden auch weiterhin einige Programme unter ihrer eigenen Benutzerkennung laufen - das ist schon wegen der Rechten des Dateisystems nötig, die SE Linux nicht ersetzt. Durch die getrennte Benutzerverwaltung ist die Rechteverwaltung beider Komponenten unabhängig voneinander, ein Zugriff muss in beiden erlaubt sein um zu gelingen.
Die nächste Abstraktionsebene sind Rollen (RBAC, Role-Based Access Control). Sie sind frei definierbar. Es ist möglich, mehrere Prozesse und Programme unter einer gemeinsamen Rolle laufen zu lassen. Die Rollen orientieren sich an den Aufgaben, für die ein Prozess oder eine Datei zuständig ist. Die im Folgenden verwendete Beispielkonfiguration nutzt drei Rollen: »system_r«, »sysadm_r« und »user_r«. Alle Systemprozesse laufen in der Rolle »system_r«, die normalen Benutzer sind »user_r« zugeordnet und Administratoren sind Mitglieder der »sysadm_r«-Rolle.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
