SELinux

SELinux (Security-Enhanced Linux; engl. „sicherheitsverbessertes Linux“) ist eine Erweiterung des Linux-Kernels, die den ersten Versuch darstellt, das FLASK-Konzept („Flux Advanced Security Kernel“) des US-amerikanischen Geheimdienstes NSA umzusetzen. Es implementiert die Zugriffskontrollen auf Ressourcen im Sinne von Mandatory Access Control. SELinux wurde maßgeblich von der NSA und von dem Linux-Distributor Red Hat entwickelt. Unternehmen wie Network Associates, Secure Computing Corporation und Tresys sind bzw. waren ebenfalls an der Arbeit an SELinux beteiligt, besonders Tresys übernahm vermehrt Aufgaben am Projekt.

SELinux ist Open-Source-Software und setzt sich aus einem Kernel-Patch und aus zahlreichen Erweiterungen für Systemprogramme sowie den SELinux-Policies zusammen. Für das Festlegen dieser Regeln, die Zugriffskontrolle auf Ressourcen, bieten einige, nicht alle Linux-Distributionen spezielle SELinux-Policy-Pakete für ihre Distribution an.

SELinux ist seit Linux-2.6.x im Kernel integriert. Die Linux-Distribution Fedora (ein durch Red Hat gesponsertes Projekt) war die erste Distribution, die standardmäßig SELinux-Unterstützung mitliefert. Fedora Core 3 und Red Hat Enterprise Linux 4 wurden als erste Distributionen mit voller SELinux-Unterstützung ausgeliefert. Mittlerweile ist es ebenfalls fester Bestandteil von AlmaLinux, Rocky Linux, Oracle Linux sowie CentOS und Hardened Gentoo. Bei Ubuntu, Debian und openSUSE bzw. SLES sind die SELinux-Tools sowie stellenweise auch SELinux-Policies über die Paketverwaltung nachinstallierbar.[1][2] Jedoch kann man nicht immer ausgefeilte Policies wie bei den RHEL-basierten Distributionen erwarten.[3] Die Implementierung für Slackware ist noch in Arbeit. Mit Einführung von Android 4.3 wurde auch offiziell der auf dem Linux-Kernel basierende Android-Kernel um SELinux erweitert.[4] Zuvor haben bereits Hersteller wie HTC und Samsung in ihren Smartphone-Modellen die Kernelerweiterung eingesetzt, um erweiterte Sicherheitsfunktionen zu implementieren.[5]

Die beiden Hauptziele von SELinux sind:

• Mandatory Access Control stellt sicher, dass eine Applikation (oder ein Benutzer) sich nicht über administrative Vorgaben hinwegsetzen kann. Ein Beispiel dafür ist, dass eine Applikation anderen Applikationen keinen Zugriff auf ihre Dateien gewähren kann und sie auch nicht ausführbar machen kann.
• Da viele Daemonen als root laufen (oder zumindest starten), möchte man einen Schutzmechanismus haben, über den der root-Benutzer sich nicht hinwegsetzen kann, so dass man wirksam einschränken kann, was ein Prozess tun kann, der als root oder mit entsprechenden capabilities läuft.

SELinux ist ein Linux Security Module (LSM), das heißt, es fügt sich in eine Sicherheitsstruktur des Kernels ein. SELinux läuft gleichzeitig mit kleinen, spezialisierten LSMs (die Beispielausgabe ist von Debian Trixie)

$ cat /sys/kernel/security/lsm
lockdown,capability,landlock,yama,selinux,bpf,ipe,ima,evm

aber es kann nicht gleichzeitig mit einem der großen anderen LSMs laufen (AppArmor, Smack, TOMOYO).

SELinux identifiziert die Sicherheitskategorie von Dateien über das geschützte erweiterte Dateiattribut security.selinux (AppArmor identifiziert sie über Pfade). Damit können Dateien im selben Verzeichnis auf einem SELinux-System völlig unterschiedlichen Regeln unterworfen sein, je nachdem, welcher Prozess(-Kontext) sie dort angelegt hat.

Die häufigste Prüfung ist die, ob ein Prozess den gewünschten Zugriff (erzeugen, lesen, schreiben, löschen, umbenennen) auf eine Datei bekommt. Aber SELinux schützt nicht nur Dateien:

• SELinux verhindert, dass ein Prozess sich an einen nicht erlaubten TCP-Port bindet oder mit einem nicht erlaubten Port eines anderen Systems verbindet.
• SELinux verhindert, dass ein Prozess sich mit nicht erlaubten IP-Adressen eines anderen Systems verbindet.
• SELinux verhindert, dass ein Prozess einen Wechsel zu einer nicht erlaubten Domain (type des SELinux-Kontexts) durchführt.
• SELinux verhindert, dass ein Benutzer einen Wechsel zu einer nicht erlaubten role durchführt.
• SELinux kann verhindern, dass ein Prozess capabilities (granulare root-Privilegien) verwendet.
• SELinux kontrolliert, welche Prozesse Dateisysteme mounten können.
• SELinux kontrolliert nicht nur den Zugriff auf IP-Adressen und Ports, sondern auch auf Sockets.

SELinux identifiziert die relevanten Elemente über ihren so genannten Kontext.

Die meisten SELinux-Konfigurationen beschränken sich auf die drei Elemente

• SELinux user
• SELinux role
• SELinux type

Es werden nur wenige User und Rollen für die meisten Prozesse und Objekte genutzt. Effektiv beschränkt sich das SELinux-Regelwerk auf die Prüfung, was der Typ eines Prozesses mit dem Typ eines Objekts tun darf (und wird deshalb als type enforcement bezeichnet).

SELinux arbeitet so, dass es prüft, ob eine Domain das Recht für den angeforderten Zugriff auf das jeweilige Objekt hat. Eine Domain ist in der SELinux-Terminologie der Typ eines Prozesses, ein Objekt ist etwas, auf das der Prozess zugreifen will, etwa eine Datei oder einen TCP-Port.

Der SELinux-Kontext hat bei Prozessen und Objekten dieselbe Struktur.

Sowohl ls als auch ps verwenden die Option -Z, um die Ausgabe der SELinux-Kontexte zu aktivieren. Ohne -Z zeigt ls -l (wenn die Datei keine ACLs hat) am Ende der Standardrechte einen Punkt an, der auf einen vorhandenen Sicherheitskontext hinweist. Dies ist nicht spezifisch für SELinux, sondern passiert auch bei Smack.

$ ls -l
total 4
drwxr-x---. 2 root root 4096 Oct 15 01:15 directory
-rw-r-----. 1 root root    0 Oct 15 01:15 file

$ ls -lZ
total 4
drwxr-x---. 2 root root unconfined_u:object_r:user_home_t:s0 4096 Oct 15 01:15 directory
-rw-r-----. 1 root root unconfined_u:object_r:user_home_t:s0    0 Oct 15 01:15 file

Die ps-Ausgabe ist zwecks besserer Übersichtlichkeit in beide Richtungen gekürzt:

$ ps -Z aux
LABEL                           USER         PID COMMAND
system_u:system_r:init_t:s0     root           1 /sbin/init
system_u:system_r:kernel_t:s0   root           2 [kthreadd]
system_u:system_r:syslogd_t:s0  root         309 /usr/lib/systemd/systemd-journald
system_u:system_r:systemd_resolved_t:s0 systemd+ /usr/lib/systemd/systemd-resolved
system_u:system_r:ntpd_t:s0     systemd+     337 /usr/lib/systemd/systemd-timesyncd
system_u:system_r:udev_t:s0     root         372 /usr/lib/systemd/systemd-udevd
system_u:system_r:systemd_networkd_t:s0 systemd+ /usr/lib/systemd/systemd-networkd
system_u:system_r:systemd_logind_t:s0 root   620 /usr/lib/systemd/systemd-logind
system_u:system_r:sshd_t:s0     root         639 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
system_u:system_r:getty_t:s0    root         651 /sbin/agetty -o -- \u --noreset --noclear - linux
system_u:system_r:sshd_t:s0     root         757 sshd-session: root@pts/0
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 731 /usr/lib/systemd/systemd --user
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 758 -bash

Ein wenig verbreitetes Feature von SELinux ist UBAC, das für die meisten Domains und Typen unterbindet, dass ein Prozess auf Prozesse oder Objekte mit einem anderen SELinux-User zugreifen kann.

Die meisten der typischen SELinux-Policies (Ausnahme: strict) haben einen speziellen Kontext, der gewissermaßen das SELinux-Äquivalent zum Superuser root ist:

unconfined_u:unconfined_r:unconfined_t

Prozesse mit diesem Kontext (entscheidend ist auch hier der Typ / die Domain) sind fast keinen SELinux-Beschränkungen unterworfen. Ein normaler Linux-User bekommt dadurch nicht mehr Rechte, aber ein root-Prozess mit diesem Kontext kann auf einem SELinux-System quasi genauso uneingeschränkt agieren wie auf einem System ohne SELinux (bzw. ohne irgendein LSM).

Die SELinux-Policies targeted, mls und mcs (nicht aber: strict) verfügen über das Feature Multi-Level-Security, das zwei zusätzliche Kriterien für die Zulässigkeit eines Zugriffs einführt:

unconfined_u:unconfined_r:unconfined_t s0-s0:c0.c1023

Der MLS-Level ist der Teil nach dem Typ. Er besteht aus zwei voneinander unabhängigen Elementen, die auch einzeln verwendet werden können:

• Sensitivity: ein hierarchisches Sicherheitsniveau (s0 ist der niedrigste; der höchste ist in der SELinux-Policy konfigurierbar). Prozesse können einen Sensitivity-Bereich haben (und damit unterschiedliche Kindprozesse mit unterschiedlichen Sensitivity-Werten erzeugen). Objekte haben üblicherweise einen konkreten Wert. SELinux verwendet standardmäßig ein abgewandeltes Bell-LaPadula-Sicherheitsmodell: Prozesse können lesend nur auf Objekte auf demselben oder einem niedrigeren Niveau zugreifen, schreibend nur auf Objekte mit demselben Niveau.
• Kategorien: Kategorien sind nicht-hierarchische Werte (typischerweise von 0 bis 1023), die als Menge funktionieren. Auf ein Objekt, dem die Kategorien c2 und c5 zugewiesen sind, kann nur ein Prozess zugreifen, dem mindestens diese beiden Kategorien zugewiesen sind. Es ist üblich, Kombinationen aus zwei Kategorien zu verwenden, um eine große Anzahl an Fällen unterscheiden zu können.

s0-s0:c0.c1023 bedeutet: Nur das niedrigste Sicherheitsniveau, aber alle Kategorien (von c0 bis c1023).

Ob MLS aktiv ist, kann man mit sestatus prüfen:

$ sestatus | grep -i mls
Policy MLS status:              enabled

Da Sensitivity-Level eher selten verwendet werden, gibt es mcs als eigene Policy, nicht aber ein Sensitivity-Äquivalent dazu. Ein häufiger Einsatzzweck von Kategorien ist die Isolation von virtuellen Maschinen oder Containern. Sie können aber auch verwendet werden, um die Trennung von Gruppen durchzusetzen. Wenn ein User eine Datei anlegt, die nur für eine Gruppe zugänglich sein soll, dann kann er die normalen Linux-Dateirechte so setzen, dass alle User oder zumindest auch andere Gruppen Zugriff haben. Eventuell muss die Datei in ein anderes Verzeichnis verschoben werden, damit andere Benutzer Zugriff bekommen. Wenn ein Prozess mit Kategorien unter SELinux eine Datei anlegt, erhält diese denselben Satz an Kategorien, und ein Prozess kann diese normalerweise nicht ändern. Wenn die Datei verschoben wird, bleiben die Kategorien erhalten.

Neben den offiziellen SELinux-Werkzeugen existieren zahlreiche Werkzeuge, die das Arbeiten mit SELinux erleichtern sollen.

Setroubleshoot benachrichtigt über ein Task-Symbol über durchgesetzte Beschränkungen von Programmen und stellt auf Anfrage zusätzliche Informationen wie auch mögliche Lösungsvorschläge bereit, um das Problem zu beheben. SLIDE ist eine IDE für die Entwicklung der Richtlinie, die in Form einer Eclipse-Erweiterung veröffentlicht wird. Das Programm apol ist für die Analyse von Richtlinien zuständig.

• AppArmor
• TrustedBSD
• PitBull LX
• TOMOYO Linux

Commons: SELinux – Sammlung von Bildern

• SELinux Project (englisch)
• Ehemaliges SELinux Project Wiki im Internet Archive (englisch)
• Ehemalige NSA-Projektseite im Internet Archive (englisch)
• Der Standard: Die NSA und die vermeintliche Linux/Android-Verschwörung

1. ↑ SpecSELinux - Ubuntu Wiki. Abgerufen am 6. Januar 2019. 
2. ↑ HardySELinux - Ubuntu Wiki. Abgerufen am 6. Januar 2019. 
3. ↑ SUSE Linux Enterprise Server Documentation / Security and Hardening Guide / SELinux / Configuring SELinux. Abgerufen am 7. Februar 2025. 
4. ↑ Neuerungen von Android 4.3 (Memento vom 5. August 2013 im Internet Archive)
5. ↑ Eike Kuehl: Android: Die NSA ist nicht nur böse. In: Zeit Online. 11. Juli 2013, abgerufen am 26. Juli 2013.