De DE/SELinux/Policies

Diskussion der Policies

SELinux ist eine sehr flexible Architektur. Sie können Ihre Policy abhängig von Ihrem Sicherheitsbedürfnis wählen.

Während der Entwicklung von SELinux haben wir bisher drei verschiedene Typen von Policies veröffentlicht: targeted (gezielt), strict and Multi-Level-Sicherheit - MLS. Die originale, von der NSA veröffentlichte Policy war die Strict-Policy. Ihr Ziel war es, das gesamte Betriebssystem und auch die Anwender zu kontrollieren. Sie hat die meisten Dämons und bedeutet für die Anwender die meisten Einschränkungen.

• Strict

Während der Entwicklung von Fedora Core 2 haben wir versucht, die Strict-Policy als Standard-Policy zu verwenden. Wir hatten damit allerdings viele Probleme, weil diese Policy die Verwendung des Rechners festlegt. Also hätten wir alle denkbaren Möglichkeiten des Aufsetzens und der Verwendung von Rechnern abbilden müssen. Wie Sie sich vorstellen können, hätte das Tonnen von Problemen und Fehlermeldungen gegeben. Die meisten der damals mit SELinux konfrontierten Anwender wollten es einfach abschalten.

Die Strict-Policy arbeitet am besten mit einem kontrollierten Userspace. Sie können beispielsweise eine Policy aufsetzen, wenn die Nutzer nur den Web-Browser und einzelne Verzeichnisse benutzen dürfen. Sie können die Anwendungen, die vom Webbrowser gestartet werden dürfen, auf Hilfsanwendungen beschränken.

• Targeted

Nach unseren Erfahrungen mit der Strict-Policy haben wir uns unsere Ziele nochmals vor Augen gehalten. Wir wollten ein System, in dem der Anwender vor Netzwerk-Systemapplikationen geschützt wird.

Diese Anwendungen waren das Einfallstor für Hackerangriffe. Daher haben wir uns entschieden, ganz gezielt - target - einige Domains in ihren Rechten zu begrenzen, während der Userspace weiter uneingeschränkt laufen durfte. Die Targeted-Policy war geboren. In Fedora Core 3 haben wir 10 Domänen für die Beschränkungen ausgemacht und haben eine neue Domän entwickelt: unconfined_t.

Prozesse innerhalb der Domän unconfined_t haben den gleichen Zugriff auf das System, als wenn SELinux nicht aktiviert wäre. Diese Policy wurde auch zur Grundlage für Red Hat Enterprise Linux 4. In Fedora Core 4 und höher haben wir weitere Ziele hinzugefügt, bis die meisten Systemprozesse beschränkt waren. Die Anwenderprozesse liefen aber weiter in der Domän unconfined_t.

In Fedora Core 5 haben wir damit begonnen, Beschränkungen für unconfined_t durch weitgehendes Entfernen der Privilegien execmem, execheap, execstack und execmod einzuführen.

• MLS

Im Rahmen der Entwicklung von Fedora Core 5/Red Hat Enterprise Linux 5 haben wir eine neue nur für Server bestimmte Policy entworfen.

Das Ziel dieser Policy ist es, dem Betriebssystem Linux die Zertifizierung nach EAL4+/LSPP zu erlauben. Damit ist es das erste Betriebssystem, das das Bell And LaPadula model und Type Enforcement mit einander verbindet. Mit dem Entwickeln dieser Policy haben wir das vierte Feld im Sicherheitskontext aktiviert werden: Der Sicherheits- oder Empfindlichkeitslevel (security or sensitivity level). Das erlaubt es uns, mit der Verwendung von labeled files zu beginnen.

Die Policy enthält Regeln, die nicht nur festlegen, was Sicherheitstypen tun dürfen, sondern auch, was sie bei der Verwendung in einer speziellen Sicherheitsebene tun dürfen. In MLS gibt es zwei Komponenten von Sicherheitsebenen: Den Empfindlichkeitslevel, der von s0 bis s15 gehen kann und den Möglichkeiten (capabilities), die von c0 bis c255 gehen können. Außerdem haben wir die MCS -Policy zu targeted und strict hinzugefügt, which confines the sensitivity level to s0, uns aber das Verwenden von nutzerdefinierten Möglichkeiten erlaubt. Damit können wir einige neue Merkmale im Betriebssystem zu testen und zu verwenden, ohne allen Anwender MLS aufbürden zu müssen.

• MLS