Linux Security Modules

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Linux Security Modules (LSM) ist ein Framework, das es dem Linux-Kernel ermöglicht unterschiedliche Computer-Sicherheitsmodelle zu unterstützen ohne dabei eine einzelne bestimmte Sicherheitsimplementierung zu bevorzugen. Das Framework steht unter GNU General Public License und ist seit Version 2.6 standardmäßig Teil des Linux-Kernels. AppArmor, SELinux, Smack und TOMOYO Linux sind die gegenwärtig offiziell im Linux-Kernel akzeptierten Module.

Entwurf[Bearbeiten | Quelltext bearbeiten]

LSM wurde entworfen um die besonderen Anforderungen zu erfüllen, die benötigt werden, um erfolgreich ein Mandatory-Access-Control-Modul zu implementieren und dabei trotzdem nur die geringstmöglichen Änderungen am Linux-Kernel vornehmen zu müssen. LSM vermeidet den Ansatz der Systemaufruf-Interposition, wie ihn Systrace verwendet, da es auf Multiprozessor-Kerneln nicht skaliert und anfällig für TOCTTOU-Attacken ist. Stattdessen fügt LSM "Hooks" (Upcalls an das Modul) an jedem Punkt im Kernel ein, bei dem ein Systemaufruf von Benutzerebene zu einem Zugriff auf ein wichtiges internes Kernelobjekt führt, wie Inodes und Task-Control-Blöcke.

Das Projekt ist eng auf die Behebung des Problems der Zugriffskontrolle fokussiert und will eine große und komplexe Änderung am Mainstream-Kernel vermeiden. Es ist nicht als allgemeiner "Hook"- oder "Upcall"-Mechanismus gedacht und unterstützt auch nicht Virtualisierung auf Betriebssystemebene.

LSMs Zielsetzung für die Zugriffskontrolle steht in enger Beziehung zum Problem des System-Auditing, weicht jedoch leicht davon ab. Auditing erfordert, dass jeder Zugriffsversuch protokolliert wird. LSM kann dies nicht leisten. Es würde viele weitere Hooks erfordern, um Fälle zu erkennen, in denen der Kernel fehlschlagende Systemaufrufe einfach abblockt und einen Fehlercode zurückgibt, bevor diese je in die Nähe wichtiger Objekte gelangen.

Der LSM-Entwurf wird in der Abhandlung Linux Security Modules: General Security Support for the Linux Kernel[1] beschrieben, die bei der USENIX Security 2002 vorgestellt wurde.[2] Bei derselben Konferenz wurde die Abhandlung Using CQUAL for Static Analysis of Authorization Hook Placement[3] diskutiert, die die automatische, statische Analyse des Kernelcodes untersucht, um zu prüfen, ob alle der benötigten Hooks tatsächlich in den Linux-Kernel integriert wurden.

Verwendung[Bearbeiten | Quelltext bearbeiten]

Entwicklung[Bearbeiten | Quelltext bearbeiten]

Auf dem Linux Kernel Summit 2001 schlug die NSA vor, dass SELinux in Linux 2.5 integriert werden könnte.[4] Linus Torvalds lehnte SELinux zu dieser Zeit ab, da er beobachtete, dass sich viele verschiedene Sicherheitsprojekte in Entwicklung befanden. Und da sie sich alle unterschieden, hatte die Gemeinde der Sicherheitsentwickler noch keinen Konsens über das ultimative Sicherheitsmodell gefunden. Stattdessen forderte Torvalds die Entwickler auf, daraus „ein Kernel-Modul zu machen“.

Als Antwort schlug[5] Crispin Cowan LSM vor: Eine Schnittstelle für den Linux-Kernel, die genügend „Hooks“ (Upcalls) von innerhalb des Linux-Kernels zu einem ladbaren Modul böte, so dass das Modul Mandatory Access Control erzwingen könnte. Die Entwicklung von LSM über die nächsten zwei Jahre wurde von der LSM-Gemeinde geleitet, einschließlich signifikanter Beiträge von Immunix Corporation, der NSA, McAfee, IBM, Silicon Graphics und vielen unabhängigen Mitwirkenden. LSM wurde schließlich für den Linux-Mainstream-Kernel akzeptiert und als Standardbestandteil von Linux 2.6 im Dezember 2003 integriert.

2006 beobachteten einige Kernel-Entwickler, dass SELinux das einzige weithin verwendete LSM-Module war, das in den Linux-Mainstream-Kernel-Quellen integriert war. Es wurde überlegt, dass, wenn es nur ein verbreitet genutztes LSM-Modul gibt, der Umweg über LSM unnötig wäre und LSM entfernt und mit SELinux selbst ersetzt werden sollte. Jedoch gibt es andere LSM-Module die außerhalb der Mainstream-Kernel-Quellen (AppArmor, Linux Intrusion Detection System, FireFlier, CIPSO, Multi ADM usw.) gepflegt werden. Dieser Meinungsaustausch hatte zwei Folgen: 1. Die Entwickler dieser Module betrieben größeren Aufwand ihre jeweiligen Module einzureichen und 2. Bekräftigte Torvalds beim Kernel Summit 2006 erneut, das LSM im Kernel bleiben würde, weil er nicht vermitteln müssen wolle, welches das beste Sicherheitsmodell wäre.

Es ist wahrscheinlich, das LSM auch weiterhin im Kernel verbleibt, da weitere Sicherheitsmodule, wie Smack (Version 2.6.25), TOMOYO Linux (Vversion 2.6.30, Juni 2009) und AppArmor (Version 2.6.36) ebenfalls für den Mainline-Kernel akzeptiert wurden.

Rezeption[Bearbeiten | Quelltext bearbeiten]

Einige Linux-Kernel-Entwickler mögen LSM aus verschiedenen Gründen nicht. LSM ist bestrebt so wenig Overhead wie möglich zu erzeugen, insbesondere, wenn kein Modul geladen ist. Aber diese Kosten sind nicht null und einige Linux-Entwickler stören sich daran. LSM wurde nur zur Bereitstellung von Zugriffskontrolle entworfen, verhindert aber nicht, dass LSM anderweitig genutzt wird und einige Linux-Kernel-Entwickler mögen nicht, dass es für andere Zwecke "missbraucht" werden kann. Insbesondere, wenn der Zweck ist, mit einem proprietären Modul die Funktionalität des Linux-Kernels zu erweitern und dabei die GPL zu umgehen.

Auch einige Sicherheitsentwickler mögen LSM nicht. Der Autor von grsecurity mag LSM wegen seiner Vorgeschichte nicht[6] und weil LSM durch den Export aller seiner Symbole, nicht nur das Einfügen von Sicherheitsmodulen, sondern auch das von schädlichen Modulen (Rootkits) ermöglicht. Der Autor von RSBAC mag LSM nicht[7], weil es in Bezug auf die Anforderungen von RSBAC unvollständig ist. Im Einzelnen argumentiert er: "Bei LSM geht es nur um zusätzliche, restriktive Zugriffskontrolle. Das RSBAC-System bietet jedoch eine Menge zusätzlicher Funktionalität, z.B. Symlink-Umleitung, secure_delete und teilweises Linux-DAC-Deaktivieren. All das muss erst zu Kernel-Funktionen in separaten Patches hinzugefügt werden.". Das Dazuko-Project argumentiert[8], dass mit der LSM-API zu arbeiten aufwändig ist, da sie sich mit jeder Kernelveröffentlichung ändert, was zusätzlichen Wartungsaufwand bedeutet. Andere Entwickler hätten LSM-Module lieber aufeinander aufbauend, z. B. die Entwickler von Yama LSM.[9]

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. ↑ Linux Security Modules: General Security Support for the Linux Kernel. Abgerufen am 3. Februar 2007.
  2. ↑ 11th USENIX Security Symposium. Abgerufen am 3. Februar 2007.
  3. ↑ Using CQUAL for Static Analysis of Authorization Hook Placement. Abgerufen am 3. Februar 2007.
  4. ↑ Linux Security Modules: General Security Hooks for Linux. Abgerufen am 26. Oktober 2015.
  5. ↑ Crispin Cowan: Linux Security Module Interface. In: linux-kernel mailing list. 11. April 2001, abgerufen am 3. Februar 2007.
  6. ↑ grsecurity. grsecurity, abgerufen am 3. Februar 2007.
  7. ↑ RSBAC and LSM. RSBAC, abgerufen am 3. Februar 2007.
  8. ↑ dazuko. dazuko, abgerufen am 26. Dezember 2017.
  9. ↑ Jake Edge: LSM stacking (again). www.lwn.net, 23. Juni 2010, abgerufen am 28. Mai 2015.
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Linux_Security_Modules&oldid=232652684“