Im letzten Beitrag über Windows und Linux bin ich unter anderem auf die jeweiligen Sicherheitsmodelle eingegangen: auf der Windows-Seite der Security Reference Monitor (SRM) mit ACLs, SIDs und MIC, auf der Linux-Seite das Linux Security Modules (LSM)-Framework mit SELinux und AppArmor. Schauen wir uns das hier mal ein wenig genauer an: Wer darf was – und warum.
Windows: Wer bist du, und was darfst du?
Der Windows-Ansatz ist im Kern identitätsbasiert. Das System fragt bei jedem Zugriff: Wer will das hier eigentlich?
Die Antwort liefert die Security Identifier (SID) – eine eindeutige, unveränderliche Kennung, die jedem Nutzer, jeder Gruppe und jedem Dienst zugewiesen wird. Eine SID sieht in der Praxis etwa so aus: S-1-5-21-3623811015-3361044348-30300820-1013. Nicht gerade einprägsam, aber das ist auch nicht ihr Job. Ihr Job ist es, unverwechselbar zu sein – auch dann, wenn jemand seinen Benutzernamen ändert.
Diese SIDs werden in Access Control Lists (ACLs) verwendet, die an jedem Objekt hängen – Dateien, Ordner, Registry-Schlüssel, Druckerwarteschlangen, Prozesse. Eine ACL besteht aus einzelnen Access Control Entries (ACEs), die schlicht sagen: SID X darf Y, SID Z darf Y nicht. Der Security Reference Monitor (SRM) im Kernel prüft bei jedem Zugriff, ob das Token des anfragenden Prozesses eine passende Erlaubnis in der ACL findet.
Das ist mächtig und granular – aber es hat einen klassischen Schwachpunkt: Wenn ein Prozess im Kontext eines Nutzers läuft, erbt er dessen Rechte. Ein kompromittierter Browser, der als normaler Nutzer läuft, kann im Rahmen dieser ACLs prinzipiell auf alle Dateien dieses Nutzers zugreifen. Genau dafür gibt es seit Windows Vista die Mandatory Integrity Control (MIC).
MIC fügt dem Ganzen eine zweite Dimension hinzu: Integritätsstufen. Prozesse und Objekte werden unabhängig von den ACLs mit einem Level versehen – Low, Medium, High, System. Der Internet Explorer führte mit dem Protected Mode erstmals Browserprozesse mit Low Integrity aus. Moderne Browser verwenden zusätzlich komplexere Sandbox-Mechanismen, die über MIC hinausgehen. Nutzerprozesse laufen auf „Medium“, elevated Prozesse auf „High“. Die Regel dabei ist simpel: Ein Prozess kann nie in ein Objekt schreiben, das eine höhere Integritätsstufe hat als er selbst. Selbst wenn die ACL es erlauben würde. MIC ist damit eine Art Sicherheitsnetz unter dem eigentlichen Berechtigungssystem.
Linux: Das klassische Unix-Modell
Bevor wir zu SELinux und AppArmor kommen, kurz der Kontext: Linux hat ein eigenes, jahrzehntealtes Basismodell. Jede Datei gehört einem Nutzer (UID) und einer Gruppe (GID), und die Berechtigungen werden in neun Bits kodiert – Read, Write, Execute, jeweils für Besitzer, Gruppe und alle anderen. Wer Root ist, spielt in diesem Bereich nach keinen Regeln.
Das funktioniert für den Hausgebrauch hervorragend. Für den Serverbetrieb hat es allerdings ein grundlegendes Problem: Es gibt keine Möglichkeit, einem Prozess zu sagen „du darfst zwar als Root laufen, aber du redest nur mit diesen Dateien und diesen Netzwerkports.“ Root ist Root.1
Das LSM-Framework wurde geschaffen, um genau diese Lücke zu schließen – und SELinux war der erste große Bewohner dieses Rahmens.
SELinux – Mandatory Access Control vom Feinsten
SELinux (Security-Enhanced Linux) wurde ursprünglich von der NSA entwickelt und 2000 als Open-Source veröffentlicht. Heute ist es der Standard auf Red Hat-basierten Systemen (RHEL, Fedora, CentOS).
Das Kernkonzept ist Type Enforcement: Jedes Objekt im System – Prozesse, Dateien, Sockets, Ports – bekommt ein Label (einen sogenannten Kontext). Ein typisches Label sieht so aus: system_u:object_r:httpd_sys_content_t:s0. Der wichtigste Teil davon ist der Typ (httpd_sys_content_t). In der Policy – einem riesigen Regelwerk, das beim Start geladen wird – steht dann sinngemäß: „Ein Prozess vom Typ httpd_t darf Dateien vom Typ httpd_sys_content_t lesen, aber nicht schreiben.“ Und nicht schreiben bedeutet nicht schreiben – egal ob Root, egal was die klassischen Unix-Rechte sagen.
Das Modell folgt dem Prinzip der minimalen Rechtevergabe konsequent. Ein Apache-Webserver kann selbst dann nichts außerhalb seines definierten Spielfelds anstellen, wenn ein Angreifer darin eine Lücke findet. Er darf einfach nicht. Die Policy erlaubt es nicht.
Der Preis dafür ist die Komplexität. SELinux-Policies sind umfangreich, die Fehlermeldungen für Einsteiger oft kryptisch, und das Debugging (ausearch, audit2allow) hat eine steile Lernkurve. Wer einmal verzweifelt nach dem Grund gesucht hat, warum ein selbst kompilierter Dienst partout keine Verbindung aufbauen wollte – obwohl die Firewall offen war und die Dateiberechtigung stimmte – der hat SELinux vielleicht kurz verflucht. Und dann doch respektiert.
AppArmor – pragmatischer Bruder
AppArmor ist auf Debian-, Ubuntu- und SUSE-basierten Systemen zu Hause und verfolgt dieselbe Grundidee – Mandatory Access Control – aber mit einem anderen Ansatz.
Statt Labels an Objekten nutzt AppArmor Profile, die an ausführbare Programme gebunden sind. Ein Profil für /usr/sbin/nginx listet auf, welche Dateipfade nginx lesen oder schreiben darf, welche Netzwerkoperationen erlaubt sind, welche Capabilities genutzt werden dürfen. Mehr nicht.
Der entscheidende Unterschied zu SELinux: AppArmor arbeitet mit Pfaden, SELinux mit Labels. Das macht AppArmor deutlich zugänglicher – ein Profil liest sich fast wie eine Konfigurationsdatei, nicht wie eine Sprache für Sicherheitsexperten. Gleichzeitig ist dieser Ansatz weniger präzise: Wenn eine Datei an einen anderen Pfad verschoben wird, greift das Profil möglicherweise nicht mehr korrekt. SELinux interessiert das nicht, weil das Label an der Datei klebt, nicht am Pfad.
AppArmor kennt zwei Modi: Enforce (Verstöße werden blockiert) und Complain (Verstöße werden nur geloggt). Letzteres ist beim Erstellen neuer Profile sehr praktisch.
Übersicht
| Merkmal | Windows SRM (ACL/SID/MIC) | SELinux | AppArmor |
|---|---|---|---|
| Grundprinzip | Identitätsbasiert (Wer?) | Labelbasiert (Was ist was?) | Pfadbasiert (Was darf dieses Programm?) |
| Durchsetzung | Mandatory (MIC) + Discretionary (ACL) | Mandatory Access Control | Mandatory Access Control |
| Granularität | Sehr hoch (pro Objekt, pro SID) | Sehr hoch (Labels auf allem) | Mittel (Pfade, Capabilities) |
| Konfiguration | GUI + PowerShell, zentral | Textbasierte Policy, komplex | Textbasierte Profile, lesbar |
| Lernkurve | Mittel | Steil | Moderat |
| Typische Plattform | Windows (alle Editionen) | RHEL, Fedora, Android | Ubuntu, Debian, SUSE |
| Root kann Policy umgehen? | Teilweise (MIC hat Grenzen) | Nein (mit enforcing Policy) | Nein (mit enforce-Modus) |
| Sichtbarkeit für Nutzer | Mittel (Fehlermeldungen bekannt) | Gering (kryptische Logs) | Mittel (Complain-Modus hilfreich) |
| Schwachstelle | ACL-Vererbung durch Prozesse | Komplexität der Policy | Pfadwechsel hebelt Profile aus |
Fazit: Zwei Welten, ein Ziel
Alle drei Mechanismen verfolgen dasselbe Ziel: sicherstellen, dass ein kompromittierter Prozess nicht gleich das ganze System mit sich reißt. Wie sie das tun, spiegelt aber die unterschiedliche DNA der Systeme wider.
Windows denkt in Identitäten und Besitzverhältnissen – nachvollziehbar für eine Plattform, die aus der Desktop-Welt kommt, in der Nutzer und ihre Rechte im Mittelpunkt stehen. SELinux denkt in streng definierten Rollen und Typen – passend für ein System, das in Hochsicherheitsumgebungen geboren wurde. AppArmor macht denselben Job zugänglicher, akzeptiert dafür aber kleinere Abstriche bei der Präzision.
Wer eine kritische Serverinfrastruktur betreibt, kommt um SELinux oder AppArmor kaum herum. Wer einfach nur wissen wollte, warum sein frisch installierter Dienst auf dem Linux-Server nichts tut obwohl alles stimmt – der weiß es jetzt zumindest.
- Genau genommen gibt es im modernen Linux Kernel Capabilities, mit denen Root-Rechte begrenzt werden können. Diese bieten aber keine umfassenden Berechtigungen. ↩︎
