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

Sprachenübersicht/Betriebssysteme/Linux/Security

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

Diese Seite wurde 8751 mal aufgerufen.

Dieser Artikel wurde in einem Wikiweb System geschrieben, das heißt, Sie können die Artikel jederzeit editieren, wenn Sie einen Fehler gefunden haben, oder etwas hinzufügen wollen.

Editieren Versionen Linkpartnerschaft Bottom Printversion

Keywords: SELinux, SELinux model, SE Linux, Installieren, sicher, Linux, role, action, subject, object

Inhaltsverzeichnis

• Vorwort
  
• Tutorials in dieser Artikelserie
  
• Das SELinux Modell
  
• Policytypen
  
• Permissive und Enforcing Mode
  
• SELinux beim booten abschalten
  
• Performance
  
• Den security context ändern
  
• 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 lehrern.

Tutorials in dieser Artikelserie Top

• 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

Das SELinux Modell Top

Wie schon erwähnt implementiert SELinux 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 braucht.

Jeder Prozess wird einer sogenannten Domain zugeordnet, jede Domain ist dazu berechtigt bestimme Dinge zu tun, keine anderen. Damit die Berechtigungen zugeordnet werden hat jede Datei mit einer Information bestückt, die "security context" genannt wird. Eine Domain bestimmt, das nur auf eine Datei zugegriffen werden kann, die den passenden security context hat. Unter speziellen Bedingungen kann ein Programm zu einer neuen Domain übergehen (wird als transition bezeichnet), die mehr, oder weniger Privilegien bietet.

Die Definition der Domains, security contexts, und das übergehen in andere Domains in einer "policy file" (was soviel wie Regelwerk bedeutet) gespeichert. Die Aufgabe von uns ist es diese Datei an das System anzupassen, sie kann vom Systemadministrator verändert werden.

Das Konzept von SELinux hat drei wichtige Klassen: Objects, Subjects, Actions.

Subjects sind, äquivalent zur deutschen Sprache, Dinge, die eine Aktion auf ein Objekt machen wollen.

• Prozesse

• Links

• Dateien

• File Descriptors

• Verzeichnisse

• Block devices, character devices, sockets, ...

Prozesse können sowohl als Subject, als auch als Object (ich nehme hier, wie bei anderen SELinux spezifischen Wörter die englische Version, da es so gut wie keine deutsche Dokumente die sich mit SELinux beschäftigen gibt) agieren.

Zu den Actions zählen: schreiben, lesen, unlock, umbenennen, speeren, link, ausführen, erstellen, editieren, Eigenschaften auslesen, ...

SELinux benutzt für die Objects, und Subjects "security contexts", die aus drei "security attributes" bestehen:

• User Identity
  
  Die User Identity verbindet den SELinux Benutzer Account mit dem Subject, oder Object. Durch den User Identity bestimmt der Benutzer account mit welchen Rechten ein Prozess läuft. Der User Account von SELinux hat übrigens nichts mit dem Benutzer Account von /etc/passwd zu tun.

• Role
  
  Ein SELinux Benutzer kann in eine Role schlüpfen, die ihm bestimmte Berechtigungen geben, mit dem Befehl newrole kann der Benutzer, ähnlich wie beim beim su Befehl die Role wechseln.
  

• Type
  
  Unter SELinux mit Domain gleichzusetzen. Siehe oben.
  

Security contexts werden in einer Tabelle gespeichert, jeder Tabelleneintrag bekommt eine SID (Security identifier). Subjects führen actions aus, und wechseln deshalb oft die role, Objects werden nur benutzt, und bleiben deshalb bei der selben role. Standardmässig bekommt ein object die role object_r. Es gibt eine naming convention für security contexts: roles hören mit _r und types mit _t auf.

Es gibt zwei Typen von Objects: transient-und persistent Objects. Transient Objects sind temporäre Objects, die nur für eine, meist kurze Zeit leben, während persistent Objects eine unbestimmte Lebensdauer haben. In der Praxis sind persistent Objects Dateien und Ordner, und transient Objects Prozesse.

Es gibt zwei verschiedene Entschiedungen die vom selinux security server getroffen werden:

• Access decisions (Zugriffskontrolle) entscheidet, ob ein existierendes Subject eine Operation auf ein Object durchführen darf. Für diese Entscheidung gibt es einen sogenannten accesss 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, 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:

• 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.

• File creation
  Eine neue Datei, oder Verzeichniss wird entweder mit dem gleichen security context des Verzeichnisses darüber, oder mit einer neuen Domain(file-type transition) erstellt.

Policytypen Top

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 (gleich wie enforcing=1). Wenn SELinux abgeschaltet ist, werden die file labels von neuen, oder editieren 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 .

Den security context ändern Top

Wir nehmen an, wir haben SELinux erfolgreich installiert. Unser erster Schritt wird es sein, sich als root einzuloggen, und in die sysadm_r role zu schlüpfen.

Wir loggen uns wie gewohnt ein, und führen den Befehl id aus:

Wir sind root, wir haben die role user_r und sind in der domain(t für type) user_t.

Das ändern wir jetzt:

Wir haben unsere security context geändert.

Als nächstes sollten wir uns vielleicht noch die security contexts von ein paar Dateien und Prozessen anschauen. Dazu verwenden wir bei ls und ps den Parameter -Z.

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 SELinux behandeln.

Gibt es noch irgendwelche Fragen, oder wollen Sie über den Artikel diskutieren?

Editieren Versionen Linkpartnerschaft Top Printversion

Haben Sie einen Fehler gefunden? Dann klicken Sie doch auf Editieren, und beheben den Fehler, keine Angst, Sie können nichts zerstören, das Tutorial kann wiederhergestellt werden

Sprachenübersicht/Betriebssysteme/Linux/Security/Ein sicheres Linux System aufsetzen Teil 1.1 - Security Enhanced Linux: SELinux Modell