Gewöhnlich verwenden Programme stets den Account des Benutzers, der sie auch startet. Wichtige Programme wie die der Netzwerkdienste oder Datenbank-Server werden mit root-Rechten gestartet, wechseln dann aber in einen Account mit eingeschränkten Rechten. Das Rechtesystem unter Unix und damit auch unter Linux ist verhältnismäßig einfach und bietet damit aber auch nur eingeschränkte Konfigurationsmöglichkeiten. Das bedeutet, wenn ein Angreifer die Kontrolle über ein Programm übernehmen kann, dann kann er auf viele Dateien zugreifen, die das Programm normalerweise noch nicht einmal benötigt. Läuft also ein Programm unter Root-Rechten kann eigener, schadhafter Code über Umwege eingespielt und ausgeführt werden.
Deshalb wird man immer vermeiden, dass Programme dauerhaft unter Root-Rechten ausgeführt werden. Die bewährtesten Sicherheitsmassnahmen sind die, auf Dämonen mit root-Rechten zu verzichten und Programme respektive Scripts möglichst nicht mit dem setuid-Bit zu installieren.
Wesentlich mehr Sicherheit bietet das von der NSA als Open-Source-Code entwickelte SELinux als Kernelerweiterung. SELinux (Security Enhanced Linux) ist ein System mit Mandatory Access Control, das auf der LSM-Schnittstelle (Linux Security Modules) von Linux aufbaut. Praktisch befragt der Kernel SELinux vor jedem Systemaufruf, um herauszufinden, ob der Prozess autorisiert ist, den jeweiligen Vorgang auszuführen. Dazu verwendet SELinux einen Satz von Regeln - in ihrer Gesamtheit als Policy bezeichnet - um Vorgänge zu autorisieren oder zu verbieten. Diese Regeln sind schwierig zu erstellen. Glücklicherweise werden zwei Standardregelwerke (targeted und strict) bereitgestellt, die den Großteil der Konfigurierungsarbeit entbehrlich machen.
MAC-Regeln bieten somit eine sehr viel engmaschigere Sicherheitskontrolle als das Unix-Zugriffsystem es bieten kann. Somit kann einem Programm generell den Zugriff auf bestimmte Verzeichnisse oder Netzwerkfunktionen unabhängig von Unix-Accounts respektive -Zugriffrechten verbieten. Selbst wenn das Programm verursacht durch einen Fehler oder Sicherheitsmängel außer Kontrolle gerät, greifen die Regel noch, da sie auf der Kernelebene überwacht werden.
Allerdings bleibt SELinux ohne die entsprechenden Regeln wirkungslos. Ob also ein System mit dem Einsatz von SELinux sicherer wird, hängt ganz entscheidend von der Qualität des Regelwerkes ab.
Da Dateien mit Extended Attributes gekeinzeichnet werden müssen, kommen nur EA-kompatible Dateisysteme in Frage, womit NFS definitiv ausscheidet.
Zwei Fundamente bilden die Grundlage zu SELinux. Zum Einen kennzeichnet ein Sicherheitskontext alle Dateien und Prozesse, zum anderen gibt es die Regeln, die die überwachten Prozesse einzuhalten haben. So sind die Objekte (z.B. Dateien) und jedes Subjekt (z.B. Prozesse) an einem Sicherheitskontext gekoppelt. Dieser Sicherheitskontext lässt sich mit
# ls -Z /etc/hosts
system_u:object_r:net_conf_t:s0 /etc/hosts
ermitteln, oder alternativ mit
# getfattr -n security.selinux -d /etc/hosts
# file: etc/hosts
security.selinux="system_u:object_r:net_conf_t:s0"
Der Kontext bei den Prozessen wird als Domäne bezeichnet. Diesen Sicherheitskontext einer Domäne ermittelt man mit
# ps axZ
LABEL PID TTY STAT TIME COMMAND
system_u:system_r:init_t:s0 1 ? Ss 0:00 /sbin/init
system_u:system_r:kernel_t:s0 2 ? S 0:00 [kthreadd]
system_u:system_r:kernel_t:s0 3 ? S 0:00 [ksoftirqd/0]
...
Normalerweise übernimmt der Prozess den Kontext des Accounts, mit er gestartet wird. Durch eine SELinux-Regel lässt sich der Kontext aber auch direkt nach dem Start verändern.
Der Sicherheitskontext gestaltet aus drei oder vier Teilen, die durch Doppelpunkte getrennt sind:
benutzer:rolle:typ:mls-komponente
Dabei ist der Typ der Datei oder des Prozesse der wichtigste Teil an der dritten Stelle. Denn die meisten SELinux-Regeln werten diese Information aus. Eine detailierte Beschreibung der Sicherheitskonzept-Komponenten ist hier zu finden fedoraproject.org/wiki/Security_context.
Eine typische SELinux-Regel baut sich nach folgender Syntax auf
allow type1_t type2_t:class { operations };
Die folgende Regel erlaubt zum Beipiel den Prozessoren, die den Kontext httpd_t angehören, in Verzeichnissen mit dem Kontexttyp httpd_log_t neue Dateien anzulegen:
allow httd_t httpd_log_t:dir create;
Direkt nach der Installation gibt es für viele Verzeichnisse passende SELinux-Regeln, die den hierin neuerzeugten Dateien die passenden Kontexte zuweisen. Sobald Dateien verschoben werden, versagt aber dieser Automatismus. In diesem Fall wird generell restorecon den Kontext wieder richtig einstellen.
restorecon -R -v /var/www/html/*
korrigiert zum Beispiel den Kontext aller im DocumentRoot-Verzeichnis des Apache gespeicherten Dateien. Wenn hingegen die HTML-Dateien unter /srv/www liegen, dann muss der richtige Kontext mit chcon eingestellt werden:
chcon -R system_u:object_r:httpd_sys_content_t:s0 /srv/www
Welchen Kontext man verwenden kann, liefern die man-Seiten, in denen die SELinux-Regeln für unterschiedliche Programme dokumentiert sind. man apache_selinux liefert die Regeln für die Kontexte des Apache-Servers.