Linux Security Modules - Versionsgeschichte

Dovahiki: /* growthexperiments-addlink-summary-summary:2|0|0 */

2025-04-09T08:16:52Z

Linkvorschlag-Funktion: 2 Links hinzugefügt.

← Nächstältere Version		Version vom 9. April 2025, 10:16 Uhr
Zeile 2:		Zeile 2:

	== Entwurf ==		== Entwurf ==
	LSM wurde entworfen um die besonderen Anforderungen zu erfüllen, die benötigt werden, um erfolgreich ein [[Mandatory Access Control\|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 [[Time-of-Check-to-Time-of-Use-Problem\|TOCTTOU]]-Attacken ist. Stattdessen fügt LSM "[[Hook (Informatik)\|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.		LSM wurde entworfen um die besonderen Anforderungen zu erfüllen, die benötigt werden, um erfolgreich ein [[Mandatory Access Control\|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 [[Time-of-Check-to-Time-of-Use-Problem\|TOCTTOU]]-Attacken ist. Stattdessen fügt LSM "[[Hook (Informatik)\|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 [[Containervirtualisierung\|Virtualisierung auf Betriebssystemebene]].		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 [[Containervirtualisierung\|Virtualisierung auf Betriebssystemebene]].
Zeile 22:		Zeile 22:
	Als Antwort schlug<ref>{{Cite web\|url=http://marc.info/?l=linux-kernel&m=98695004126478&w=2\|title=Linux Security Module Interface\|date=2001-04-11\|accessdate=2007-02-03\|last=Crispin Cowan\|work=linux-kernel mailing list}}</ref> Crispin Cowan LSM vor: Eine Schnittstelle für den Linux-Kernel, die genügend „Hooks“ (Upcalls) von innerhalb des Linux-Kernels zu einem [[Kernel-Modul\|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 [[National Security Agency\|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.		Als Antwort schlug<ref>{{Cite web\|url=http://marc.info/?l=linux-kernel&m=98695004126478&w=2\|title=Linux Security Module Interface\|date=2001-04-11\|accessdate=2007-02-03\|last=Crispin Cowan\|work=linux-kernel mailing list}}</ref> Crispin Cowan LSM vor: Eine Schnittstelle für den Linux-Kernel, die genügend „Hooks“ (Upcalls) von innerhalb des Linux-Kernels zu einem [[Kernel-Modul\|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 [[National Security Agency\|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.		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.		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.

InternetArchiveBot: InternetArchiveBot hat 1 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert.) #IABot (v2.0.9.5) (GünniBusch - 23116

2025-03-21T02:54:30Z

InternetArchiveBot hat 1 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert.) #IABot (v2.0.9.5) (GünniBusch - 23116

← Nächstältere Version		Version vom 21. März 2025, 04:54 Uhr
Zeile 18:		Zeile 18:

	== Entwicklung ==		== Entwicklung ==
	Auf dem Linux Kernel Summit 2001 schlug die [[National Security Agency\|NSA]] vor, dass [[SELinux]] in Linux 2.5 integriert werden könnte.<ref>{{Cite web\|url=http://www.hep.by/gnu/kernel/lsm/\|title=Linux Security Modules: General Security Hooks for Linux\|accessdate=2015-10-26}}</ref> [[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“.		Auf dem Linux Kernel Summit 2001 schlug die [[National Security Agency\|NSA]] vor, dass [[SELinux]] in Linux 2.5 integriert werden könnte.<ref>{{Cite web\|url=http://www.hep.by/gnu/kernel/lsm/\|title=Linux Security Modules: General Security Hooks for Linux\|accessdate=2015-10-26\|archiveurl=https://web.archive.org/web/20160304092032/http://www.hep.by/gnu/kernel/lsm/\|archivedate=2016-03-04\|offline=0\|archivebot=2025-03-21 02:54:30 InternetArchiveBot}}</ref> [[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<ref>{{Cite web\|url=http://marc.info/?l=linux-kernel&m=98695004126478&w=2\|title=Linux Security Module Interface\|date=2001-04-11\|accessdate=2007-02-03\|last=Crispin Cowan\|work=linux-kernel mailing list}}</ref> Crispin Cowan LSM vor: Eine Schnittstelle für den Linux-Kernel, die genügend „Hooks“ (Upcalls) von innerhalb des Linux-Kernels zu einem [[Kernel-Modul\|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 [[National Security Agency\|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.		Als Antwort schlug<ref>{{Cite web\|url=http://marc.info/?l=linux-kernel&m=98695004126478&w=2\|title=Linux Security Module Interface\|date=2001-04-11\|accessdate=2007-02-03\|last=Crispin Cowan\|work=linux-kernel mailing list}}</ref> Crispin Cowan LSM vor: Eine Schnittstelle für den Linux-Kernel, die genügend „Hooks“ (Upcalls) von innerhalb des Linux-Kernels zu einem [[Kernel-Modul\|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 [[National Security Agency\|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.

Nesevra: /* growthexperiments-addlink-summary-summary:1|2|0 */

2024-09-18T11:19:26Z

Linkvorschlag-Funktion: 1 Link hinzugefügt.

← Nächstältere Version		Version vom 18. September 2024, 13:19 Uhr
Zeile 8:		Zeile 8:
	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.		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''<ref>{{Cite web\|url=http://www.usenix.org/event/sec02/wright.html\|title=Linux Security Modules: General Security Support for the Linux Kernel\|accessdate=2007-02-03}}</ref> beschrieben, die bei der USENIX Security 2002 vorgestellt wurde.<ref>{{Cite web\|url=http://www.usenix.org/event/sec02/\|title=11th USENIX Security Symposium\|accessdate=2007-02-03}}</ref> Bei derselben Konferenz wurde die Abhandlung ''Using CQUAL for Static Analysis of Authorization Hook Placement''<ref>{{Cite web\|url=http://www.usenix.org/event/sec02/zhang.html\|title=Using CQUAL for Static Analysis of Authorization Hook Placement\|accessdate=2007-02-03}}</ref> 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.		Der LSM-Entwurf wird in der Abhandlung ''Linux Security Modules: General Security Support for the Linux Kernel''<ref>{{Cite web\|url=http://www.usenix.org/event/sec02/wright.html\|title=Linux Security Modules: General Security Support for the Linux Kernel\|accessdate=2007-02-03}}</ref> beschrieben, die bei der [[USENIX]] Security 2002 vorgestellt wurde.<ref>{{Cite web\|url=http://www.usenix.org/event/sec02/\|title=11th USENIX Security Symposium\|accessdate=2007-02-03}}</ref> Bei derselben Konferenz wurde die Abhandlung ''Using CQUAL for Static Analysis of Authorization Hook Placement''<ref>{{Cite web\|url=http://www.usenix.org/event/sec02/zhang.html\|title=Using CQUAL for Static Analysis of Authorization Hook Placement\|accessdate=2007-02-03}}</ref> 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 ==		== Verwendung ==

Wiki Gh!: Abkürzung mit geschütztem Leerabstand

2024-06-20T08:57:04Z

Abkürzung mit geschütztem Leerabstand

← Nächstältere Version		Version vom 20. Juni 2024, 10:57 Uhr
Zeile 29:		Zeile 29:
	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 [[GNU General Public License\|GPL]] zu umgehen.		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 [[GNU General Public License\|GPL]] zu umgehen.

	Auch einige Sicherheitsentwickler mögen LSM nicht. Der Autor von grsecurity mag LSM wegen seiner Vorgeschichte nicht<ref>{{Cite web\|url=http://www.grsecurity.net/lsm.php\|title=grsecurity\|accessdate=2007-02-03\|publisher=grsecurity}}</ref> und weil LSM durch den Export aller seiner Symbole, nicht nur das Einfügen von Sicherheitsmodulen, sondern auch das von schädlichen Modulen ([[Rootkit]]s) ermöglicht. Der Autor von RSBAC mag LSM nicht<ref>{{Cite web\|url=http://www.rsbac.org/documentation/why_rsbac_does_not_use_lsm\|title=RSBAC and LSM\|accessdate=2007-02-03\|publisher=RSBAC}}</ref>, 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<ref>{{Cite web\|url=http://dazuko.dnsalias.org/wiki/index.php/FAQ_(Dazuko_2.x)#What_are_the_known_issues_with_the_LSM_.28Linux_Security_Modules.29_system.3F\|title=dazuko\|accessdate=2017-12-26\|publisher=dazuko}}</ref>, 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.<ref>{{Cite web\|url=https://lwn.net/Articles/393008/\|title=LSM stacking (again)\|date=2010-06-23\|accessdate=2015-05-28\|last=Edge\|first=Jake\|publisher=www.lwn.net}}</ref>		Auch einige Sicherheitsentwickler mögen LSM nicht. Der Autor von grsecurity mag LSM wegen seiner Vorgeschichte nicht<ref>{{Cite web\|url=http://www.grsecurity.net/lsm.php\|title=grsecurity\|accessdate=2007-02-03\|publisher=grsecurity}}</ref> und weil LSM durch den Export aller seiner Symbole, nicht nur das Einfügen von Sicherheitsmodulen, sondern auch das von schädlichen Modulen ([[Rootkit]]s) ermöglicht. Der Autor von RSBAC mag LSM nicht<ref>{{Cite web\|url=http://www.rsbac.org/documentation/why_rsbac_does_not_use_lsm\|title=RSBAC and LSM\|accessdate=2007-02-03\|publisher=RSBAC}}</ref>, 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<ref>{{Cite web\|url=http://dazuko.dnsalias.org/wiki/index.php/FAQ_(Dazuko_2.x)#What_are_the_known_issues_with_the_LSM_.28Linux_Security_Modules.29_system.3F\|title=dazuko\|accessdate=2017-12-26\|publisher=dazuko}}</ref>, 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.<ref>{{Cite web\|url=https://lwn.net/Articles/393008/\|title=LSM stacking (again)\|date=2010-06-23\|accessdate=2015-05-28\|last=Edge\|first=Jake\|publisher=www.lwn.net}}</ref>

	== Einzelnachweise ==		== Einzelnachweise ==

Invisigoth67: typo

2024-05-05T15:44:54Z

typo

← Nächstältere Version		Version vom 5. Mai 2024, 17:44 Uhr
Zeile 1:		Zeile 1:
	'''Linux Security Modules''' ('''LSM''') ist ein [[Framework]], das es dem [[Linux (Kernel)\|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.		'''Linux Security Modules''' ('''LSM''') ist ein [[Framework]], das es dem [[Linux (Kernel)\|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 ==		== Entwurf ==

Hale-Bopp-23: /* Entwicklung */ Fix Typo.

2023-04-10T11:19:40Z

Entwicklung: Fix Typo.

← Nächstältere Version		Version vom 10. April 2023, 13:19 Uhr
Zeile 20:		Zeile 20:
	Auf dem Linux Kernel Summit 2001 schlug die [[National Security Agency\|NSA]] vor, dass [[SELinux]] in Linux 2.5 integriert werden könnte.<ref>{{Cite web\|url=http://www.hep.by/gnu/kernel/lsm/\|title=Linux Security Modules: General Security Hooks for Linux\|accessdate=2015-10-26}}</ref> [[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“.		Auf dem Linux Kernel Summit 2001 schlug die [[National Security Agency\|NSA]] vor, dass [[SELinux]] in Linux 2.5 integriert werden könnte.<ref>{{Cite web\|url=http://www.hep.by/gnu/kernel/lsm/\|title=Linux Security Modules: General Security Hooks for Linux\|accessdate=2015-10-26}}</ref> [[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<ref>{{Cite web\|url=http://marc.info/?l=linux-kernel&m=98695004126478&w=2\|title=Linux Security Module Interface\|date=2001-04-11\|accessdate=2007-02-03\|last=Crispin Cowan\|work=linux-kernel mailing list}}</ref> Crispin Cowan LSM vor: Eine Schnittstelle für den Linux-Kernel, die genügend „Hooks“ (Upcalls) von innerhalb des Linux-Kernels zu einem [[Kernel-Modul\|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 [[National Security Agency\|NSA]], [[McAfee]], [[IBM]], [[Silicon Graphics]] und vielen unabhängigen Mitwirkenden. LSM wurde schließlich für den Linux-~~Maintream~~-Kernel akzeptiert und als Standardbestandteil von Linux 2.6 im Dezember 2003 integriert.		Als Antwort schlug<ref>{{Cite web\|url=http://marc.info/?l=linux-kernel&m=98695004126478&w=2\|title=Linux Security Module Interface\|date=2001-04-11\|accessdate=2007-02-03\|last=Crispin Cowan\|work=linux-kernel mailing list}}</ref> Crispin Cowan LSM vor: Eine Schnittstelle für den Linux-Kernel, die genügend „Hooks“ (Upcalls) von innerhalb des Linux-Kernels zu einem [[Kernel-Modul\|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 [[National Security Agency\|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.		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.

Nameless23: /* Entwicklung */

2021-11-20T23:53:20Z

Entwicklung

← Nächstältere Version		Version vom 21. November 2021, 01:53 Uhr
Zeile 18:		Zeile 18:

	== Entwicklung ==		== Entwicklung ==
	Auf dem Linux Kernel Summit 2001, schlug die [[National Security Agency\|NSA]] vor, dass [[SELinux]] in Linux 2.5 integriert werden könnte.<ref>{{Cite web\|url=http://www.hep.by/gnu/kernel/lsm/\|title=Linux Security Modules: General Security Hooks for Linux\|accessdate=2015-10-26}}</ref> [[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"~~.		Auf dem Linux Kernel Summit 2001 schlug die [[National Security Agency\|NSA]] vor, dass [[SELinux]] in Linux 2.5 integriert werden könnte.<ref>{{Cite web\|url=http://www.hep.by/gnu/kernel/lsm/\|title=Linux Security Modules: General Security Hooks for Linux\|accessdate=2015-10-26}}</ref> [[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<ref>{{Cite web\|url=http://marc.info/?l=linux-kernel&m=98695004126478&w=2\|title=Linux Security Module Interface\|date=2001-04-11\|accessdate=2007-02-03\|last=Crispin Cowan\|work=linux-kernel mailing list}}</ref> Crispin Cowan LSM vor: Eine Schnittstelle für den Linux-Kernel die genügend ~~"Hooks"~~ (Upcalls) von innerhalb des Linux-Kernels zu einem [[Kernel-Modul\|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 [[National Security Agency\|NSA]], [[McAfee]], [[IBM]], [[Silicon Graphics]] und vielen unabhängigen Mitwirkenden. LSM wurde schließlich für den Linux-Maintream-Kernel akzeptiert und als Standardbestandteil von Linux 2.6 im Dezember 2003 integriert.		Als Antwort schlug<ref>{{Cite web\|url=http://marc.info/?l=linux-kernel&m=98695004126478&w=2\|title=Linux Security Module Interface\|date=2001-04-11\|accessdate=2007-02-03\|last=Crispin Cowan\|work=linux-kernel mailing list}}</ref> Crispin Cowan LSM vor: Eine Schnittstelle für den Linux-Kernel, die genügend „Hooks“ (Upcalls) von innerhalb des Linux-Kernels zu einem [[Kernel-Modul\|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 [[National Security Agency\|NSA]], [[McAfee]], [[IBM]], [[Silicon Graphics]] und vielen unabhängigen Mitwirkenden. LSM wurde schließlich für den Linux-Maintream-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.		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.

Aka: /* Entwurf */ Durchkopplung

2021-09-11T14:49:16Z

Entwurf: Durchkopplung

← Nächstältere Version		Version vom 11. September 2021, 16:49 Uhr
Zeile 2:		Zeile 2:

	== Entwurf ==		== Entwurf ==
	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 [[Time-of-Check-to-Time-of-Use-Problem\|TOCTTOU]]-Attacken ist. Stattdessen fügt LSM "[[Hook (Informatik)\|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.		LSM wurde entworfen um die besonderen Anforderungen zu erfüllen, die benötigt werden, um erfolgreich ein [[Mandatory Access Control\|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 [[Time-of-Check-to-Time-of-Use-Problem\|TOCTTOU]]-Attacken ist. Stattdessen fügt LSM "[[Hook (Informatik)\|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 [[Containervirtualisierung\|Virtualisierung auf Betriebssystemebene]].		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 [[Containervirtualisierung\|Virtualisierung auf Betriebssystemebene]].

Shilch: Korrektur: "Ins Besondere" -> "insbesondere"

2020-10-21T19:17:16Z

Korrektur: "Ins Besondere" -> "insbesondere"

← Nächstältere Version		Version vom 21. Oktober 2020, 21:17 Uhr
Zeile 27:		Zeile 27:

	== Rezeption ==		== Rezeption ==
	Einige Linux-Kernel-Entwickler mögen LSM aus verschiedenen Gründen nicht. LSM ist bestrebt so wenig Overhead wie möglich zu erzeugen, ~~ins Besondere~~, 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. ~~Ins Besondere~~, wenn der Zweck ist, mit einem proprietären Modul die Funktionalität des Linux-Kernels zu erweitern und dabei die [[GNU General Public License\|GPL]] zu umgehen.		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 [[GNU General Public License\|GPL]] zu umgehen.

	Auch einige Sicherheitsentwickler mögen LSM nicht. Der Autor von grsecurity mag LSM wegen seiner Vorgeschichte nicht<ref>{{Cite web\|url=http://www.grsecurity.net/lsm.php\|title=grsecurity\|accessdate=2007-02-03\|publisher=grsecurity}}</ref> und weil LSM durch den Export aller seiner Symbole, nicht nur das Einfügen von Sicherheitsmodulen, sondern auch das von schädlichen Modulen ([[Rootkit]]s) ermöglicht. Der Autor von RSBAC mag LSM nicht<ref>{{Cite web\|url=http://www.rsbac.org/documentation/why_rsbac_does_not_use_lsm\|title=RSBAC and LSM\|accessdate=2007-02-03\|publisher=RSBAC}}</ref>, 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<ref>{{Cite web\|url=http://dazuko.dnsalias.org/wiki/index.php/FAQ_(Dazuko_2.x)#What_are_the_known_issues_with_the_LSM_.28Linux_Security_Modules.29_system.3F\|title=dazuko\|accessdate=2017-12-26\|publisher=dazuko}}</ref>, 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.<ref>{{Cite web\|url=https://lwn.net/Articles/393008/\|title=LSM stacking (again)\|date=2010-06-23\|accessdate=2015-05-28\|last=Edge\|first=Jake\|publisher=www.lwn.net}}</ref>		Auch einige Sicherheitsentwickler mögen LSM nicht. Der Autor von grsecurity mag LSM wegen seiner Vorgeschichte nicht<ref>{{Cite web\|url=http://www.grsecurity.net/lsm.php\|title=grsecurity\|accessdate=2007-02-03\|publisher=grsecurity}}</ref> und weil LSM durch den Export aller seiner Symbole, nicht nur das Einfügen von Sicherheitsmodulen, sondern auch das von schädlichen Modulen ([[Rootkit]]s) ermöglicht. Der Autor von RSBAC mag LSM nicht<ref>{{Cite web\|url=http://www.rsbac.org/documentation/why_rsbac_does_not_use_lsm\|title=RSBAC and LSM\|accessdate=2007-02-03\|publisher=RSBAC}}</ref>, 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<ref>{{Cite web\|url=http://dazuko.dnsalias.org/wiki/index.php/FAQ_(Dazuko_2.x)#What_are_the_known_issues_with_the_LSM_.28Linux_Security_Modules.29_system.3F\|title=dazuko\|accessdate=2017-12-26\|publisher=dazuko}}</ref>, 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.<ref>{{Cite web\|url=https://lwn.net/Articles/393008/\|title=LSM stacking (again)\|date=2010-06-23\|accessdate=2015-05-28\|last=Edge\|first=Jake\|publisher=www.lwn.net}}</ref>

Girus: ty

2019-12-04T08:55:32Z

← Nächstältere Version		Version vom 4. Dezember 2019, 10:55 Uhr
Zeile 4:		Zeile 4:
	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 [[Time-of-Check-to-Time-of-Use-Problem\|TOCTTOU]]-Attacken ist. Stattdessen fügt LSM "[[Hook (Informatik)\|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.		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 [[Time-of-Check-to-Time-of-Use-Problem\|TOCTTOU]]-Attacken ist. Stattdessen fügt LSM "[[Hook (Informatik)\|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~~\|Zugriffkontrolle~~]] 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 [[Containervirtualisierung\|Virtualisierung auf Betriebssystemebene]].		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 [[Containervirtualisierung\|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.		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''<ref>{{Cite web\|url=http://www.usenix.org/event/sec02/wright.html\|title=Linux Security Modules: General Security Support for the Linux Kernel\|accessdate=2007-02-03}}</ref> beschrieben, die bei der USENIX Security 2002 vorgestellt wurde.<ref>{{Cite web\|url=http://www.usenix.org/event/sec02/\|title=11th USENIX Security Symposium\|accessdate=2007-02-03}}</ref> Bei ~~der selben~~ Konferenz wurde die Abhandlung ''Using CQUAL for Static Analysis of Authorization Hook Placement''<ref>{{Cite web\|url=http://www.usenix.org/event/sec02/zhang.html\|title=Using CQUAL for Static Analysis of Authorization Hook Placement\|accessdate=2007-02-03}}</ref> 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.		Der LSM-Entwurf wird in der Abhandlung ''Linux Security Modules: General Security Support for the Linux Kernel''<ref>{{Cite web\|url=http://www.usenix.org/event/sec02/wright.html\|title=Linux Security Modules: General Security Support for the Linux Kernel\|accessdate=2007-02-03}}</ref> beschrieben, die bei der USENIX Security 2002 vorgestellt wurde.<ref>{{Cite web\|url=http://www.usenix.org/event/sec02/\|title=11th USENIX Security Symposium\|accessdate=2007-02-03}}</ref> Bei derselben Konferenz wurde die Abhandlung ''Using CQUAL for Static Analysis of Authorization Hook Placement''<ref>{{Cite web\|url=http://www.usenix.org/event/sec02/zhang.html\|title=Using CQUAL for Static Analysis of Authorization Hook Placement\|accessdate=2007-02-03}}</ref> 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 ==		== Verwendung ==