Be-Paranoid.net

Ein sicheres Linux System aufsetzen Teil 1.1 - Security Enhanced Linux: SELinux Modell

Orginal Version | Artikel editieren | Versionen anzeigen | Bottom
Letzte Änderung: 19.08.2006, 00:25

Inhaltsverzeichnis

• Vorwort
  
• Tutorials in dieser Artikelserie
  
• Einführung
  
• Begriffe
  
• Praktisches Beispiel
  
• Permamente und flüchtige Objekte
  
• Zugriffsentscheidungen
  
• Policy
  
• Permissive und Enforcing Mode
  
• SELinux beim booten abschalten
  
• Performance
  
• Quellen
  
• Schlusswort
  

Vorwort Top

Diese Tutorialserie beschäftigt sich damit, ein sicheres Linux-System aufzusetzen. Im ersten Teil wurde beschrieben, wie man den Linux-Kernel mit SELinux patcht, und SELinux installiert.

Dieser Teil soll theoretisches Wissen über SELinux vermitteln, der dritte Teil wird die Konfiguration der policy erklären.

Tutorials in dieser Artikelserie Top

• Teil 0.0 - Linux härten

• Teil 1.0 - Security Enhanced Linux: Installation

• Teil 1.1 - Security Enhanced Linux: SELinux Modell

• Teil 1.2 - Security Enhanced Linux: Die Policy

• Teil 2.0 - Linux mit /proc härten

• Teil 3.0 - Festplattenverschlüsselung

Einführung Top

SELinux implementiert ein LMS(Linux Security Module), das auf "mandatory access controls", kurz MAC basiert, die Rolle des Benutzers stärker einschränkt, und ihm nur die Rechte gibt, die er RFCHJpdmlsZWdl.html" rel="nofollow">braucht. SELinux bietet drei Möglichkeiten, Regeln für die Zugriffskontrolle zu erstellen: Type Enforcement (TE), rollenbasierte Zugriffskontrolle (Role Base Access Control). Das ursprüngliche TE Modell vom Flask-Konzept würde Benutzer mit Domains gleichsetzen (siehe weiter unten), RBAC wurde geschaffen, um eine Abstraktion zwischen der SELinux Benutzer-Identität, und dem TE-Model zu bilden, der Benutzer kann in verschiedene Rollen schlüpfen. Die dritte Möglichkeit, ist mehrstufige Sicherheit (Multi-Level Security - MLS). MLS ist eine Erweiterung, die im moment nur experimentel Verfügbar ist, sie benutzt mehrere Sicherheitsstufen, ein Konzept aus dem militärischen Bereich, Objekte erhalten unter anderem Geheimhaltungstufen.

Begriffe Top

• Objekte, Subjekte und Aktionen
  
  Für Zugriffsentscheidungen in SELinux gibt es drei wichtige Begriffe: Subjekte, Objekte, und Aktionen. Bill McCarty beschreibt das in seinem Buch, wie ich finde, sehr gut mit der Sprache. In der Sprache gibt es Subjekte, Objekte und Verben. Ein Subjekt macht etwas (Verb, in SELinux Action) mit dem Objekt. Subjekte und Objekte können Prozesse, Links, Dateien, File Descriptors, Verzeichnisse, Block devices, character devices, sockets, ... sein. Zu den Aktionen zählen: schreiben, lesen, unlock, umbenennen, speeren, link, ausführen, erstellen, editieren, Eigenschaften auslesen, ...

• Domains und Typen
  
  Zwei weitere wichtige Begriffe sind Domain bzw. Type. Sie dienen dazu Subjekte, bzw. Objekte zu gruppieren. Subjects und Objects können einer Domain zugeordnet werden (bei Objects wird das Type genannt), diese Domain ist ein zusätzliches Attribut, das Objects und Subjects zusammenfasst, so das später Regeln für die jeweilige Domain aufgestellt werden können. Diese Regeln bestimmen, was die Domain machen darf, alles andere dürfen Objekte innerhalb einer Domain nicht machen. Domains haben normalerweise den Präfix _t (Typ). Unter speziellen Bedingungen kann ein Programm zu einer neuen Domain übergehen (wird als transition bezeichnet), die mehr, oder weniger Privilegien bietet.

• Rollen
  
  Rollen (rolles) legen fest, auf welche Objekte, oder Subjekte ein SELinux Benutzer zugreifen darf. So kann die sysadm_r (_r ist das Präfix für rolle) Rolle, der normalerweise root zugeordnet ist, nicht auf Domains von Dateien im /home Verzeichnis von anderen Benutzern zugreifen, um das zu ermöglichen müsste der Benutzer in die Rolle des jeweiligen Benutzers schlüpfen.
  
  Subjekte führen Aktionen aus, und wechseln deshalb oft die Rolle, Objects werden nur benutzt, und bleiben deshalb bei der selben Rolle.

• SELinux Benutzer-Identität
  
  Die Benutzer-Identität von SELinux ist nicht das gleiche wie die Identität vom normalen Linux-Benutzer. Sie legt fest, welche Rollen, und Domains verwendet werden können.

• Security contexts
  
  Damit Berechtigungen von Subjekten, Objekten, und Aktionen zugeordnet werden kann, gibt es für jede dieser drei Klassen ein sogenannten security context. Der security context besteht aus den drei Sicherheitsattributen (security attributes), die oben beschrieben wurden:
  
  [enum1]SELinux Benutzer-Identität[/enum1]
  [enum1]Rolle[/enum1]
  [enum1]Type[/enum1]
  
  Security contexts werden in einer Tabelle gespeichert, jeder Tabelleneintrag bekommt eine SID (Security identifier).

Praktisches Beispiel Top

SELinux hat, wie im letzten Kapitel besprochen einige Änderungen an unserem System vorgenommen, unter anderem wurden die Programme id und ls mit dem Parameter -Z erweitert.

Ich melde mich als root Benutzer an, und gebe den Befehl id -Z ein:

Code:

    
selinux:/# id -Z    
root:user_r:user_t     

Der Benutzer hat die Rolle user_r und ist Domain user_t.

Die Useridentität legt fest, das wir in die Rolle sysadm_r schlüpfen dürfen, das machen ich jetzt:

Code:

    
selinux:/# newrole -r sysadm_r -t sysadm_t    
Authenticating root.    
Password:    
selinux:/# id -Z    
root:sysadm_r:sysadm_t    

Wir haben die Rolle gewechselt, und sind jetzt in sysadm_r.

Permamente und flüchtige Objekte Top

Es gibt zwei Typen von Objects: flüchtige (transient) permamente(persitent) Objekte. Flüchtige Objekte sind temporäre Objekte, die nur für eine, meist kurze Zeit leben, während permamente Objekte eine unbestimmte Lebensdauer haben. In der Praxis sind permamente Objekte Dateien und Ordner, und flüchtige Objekte Prozesse.

Zugriffsentscheidungen Top

Es gibt zwei verschiedene Entschiedungen die vom SELinux-Security-Server getroffen werden: Access decisions, und Transient decisions.

• Access decisions
  
  Access decisions (Zugriffsentscheidungen) entscheidet, ob ein existierendes Subjekt eine Operation auf ein Objekt durchführen darf. Für diese Entscheidung gibt es einen sogenannten access vector. Man stellt ihn sich am besten als zweidimensionale boolsche Tabelle vor. Die Spalten beinhalten verschieden Aktionen wie z.B. Append, Read, Create, ... und in den Zeilen steht Allow, Auditallow oder Dontaudit. Der access vector wird vom Kernel über den AVC (access vector cache) zur jeweilen security class abgerufen.

• Transient Decisions, die Entscheidung über Wechseln von Domains
  
  Domains können, genauso wie Rollen gewechselt werden, dieser Vorgang nennt man auf englisch Transient. Transient decisions, oder labeling decisions sind Entscheidungen, die für neu erstellte Objecte (Prozesse und Dateien) gelten. Die Transient decisions entscheidet, was mit neuen Objekten geschiet, welche security context sie bekommen.
  
  Bei Transient decisions wird wieder unter zwei verschiedenen Typen unterschieden:
  
  [enum1]Process creation
  
  Der neu erstellte Prozess hat entweder die gleichen, oder eine andere Domain als der Parentprozess, wenn der Prozess in einer anderen Domain laufen soll, findet eine domain transition statt.[/enum1]
  
  [enum1]File creation
  
  Eine neue Datei oder Verzeichnis wird entweder mit dem gleichen security context des Verzeichnisses darüber, oder mit einer neuen Domain(file-type transition) erstellt.[/enum1]

Policy Top

In unserem Beispiel oben habe ich geschrieben, das die Benutzeridentität von root es uns erlaubt, die Rolle zu ändern. Ob das erlaubt ist, und wem wird in der sogenannten Policy festgelegt. Die Policy ist unser Regelwerk, sie legt fest, was gemacht werden darf, wer in welche Rolle schlüfen darf, welche security contexts Dateien bekommen und was, welche Domain benutzen darf. Die Aufgabe des Systemadministrators ist es, die Policy an das System anzupassen, und die Rechte intelligent zu vergeben. Die Policy wird ausführlich im nächsten Kapitel besprochen.

• Policytypen
  
  Nach der Aussage von SELinux Entwicklern hat die strict policy von SELinux normalen Benutzern ziemlich zu schaffen gemacht, deshalb entschieden sich die targeted policy zu erstellen, die weniger streng ist. Die targeted policy beschränkt sich auf daemons, die einen Server angreifbar machen: dhcpd, httpd, named, nscd, ntpd, portmapd, snmpd, squid and syslogd. Der Rest des Systems läuft in der unconfined_t domain, so als ob SELinux nicht benutzt würde.

Permissive und Enforcing Mode Top

Bei SELinux gibt es zwei verschiedene Modi, den permissive und enforcing mode:

• Permissive mode:
  
  Hier wird die SELinux policy nicht umgesetzt, es werden lediglich Warnungen bei Policy-Verletzungen ausgegeben. Dieser Modus wird dazu genutzt die policy zu testen, man sollte das nur in einer gesicherten Umgebung machen.

• Enforcing mode:
  
  Im enforcing mode setzt SELinux alle Entscheidungen um, die gefällt werden.

Der enforcing mode kann im bootloader entweder an, oder ausgeschaltet werden. Bei GRUB geschieht dies in der Datei /boot/grub/menu.conf, das haben wir schon im letzten Artikel (weiter unten im Kapitel kernel-builden) schon gemacht. Wenn es ihnen zu unsicher ist, das jemand im permissive mode booten können Sie auch eine Boot-CD mit einem Kernel machen, der den permissive mode unterstützt. Der "normale" Kernel kann ohne permissive mode erstellt werden, in dem die Option NSA SELinux Development support nicht aktiviert wird. Ausserdem können Sie eine neue policy auf einer Kopie vom System testen, dann müssen Sie ihr System nicht neustarten. Mit dem Befehl setenforce 0 oder setenforce 1 können Sie zwischen permissive und enforcing mode wechseln, dazu müssen Sie allerdings die sysadm_r rolle besitzen. Alternativ können Sie auch die Flags im selinux-pseudofilesystem ändern. (echo 0 > /selinux/enforce)

SELinux beim booten abschalten Top

Wenn der Kernel mit der Option NSA SELinux boot parameter kompiliert wurde, kann SELinux beim booten abgeschaltet werden, dazu muss der Wert selinux=0 an GRUB übergeben werden (wie enforcing=1). Wenn SELinux abgeschaltet ist, werden die file labels von neuen, oder veränderten Dateien nicht angepasst, um Probleme zu verhindern müssen Sie das Dateisystem neu labeln, so wie wir es im ersten Teil der Tutorialserie gemacht haben. Das gleiche gilt, wenn die Partition von einer LiveCD oder ähnlichem verändert wird.

Performance Top

Wenn der SELinux Security Server läuft, kostet das einiges an CPU Zeit, auf manchen System kann es die CPU um 7% auslasten. Ich denke dass, das verkraftbar ist, im Vergleich zu dem was SELinux bietet, immerhin ist es nichts im Vergleich zu den 30%-40% die ein Personal Firewall, oder ein Virenscanner braucht, vorallem wenn man die Tatsache berücksichtigt das SELinux wircklich was bringen kann .

Quellen Top

• SELinux - NSA's Open Source Security Enhanced Linux ISBN:0-596-00716-7 - O'Reilly

• NSA Papers

• Wikipedia - SELinux

Schlusswort Top

In diesem Kapitel haben wir gelernt, wie SELinux grundlegend funktioniert: was security contexts sind, wie Entscheidungen getroffen werden, und wie wir als Benutzer unsere Rechte ändern.

Das nächste Kapitel wird die Konfiguration von der SELinux Policy behandeln.

Orginal Version | Artikel editieren | Versionen anzeigen | Top
Letzte Änderung: 19.08.2006, 00:25