knowledgr.de

Sicherheitserhöhter Linux

Neues Wissen!

Sicherheitserhöhter Linux (SELinux) ist eine Eigenschaft von Linux, die einen Mechanismus zur Verfügung stellt, um Zugriffskontrollsicherheitspolicen einschließlich obligatorischer mit dem Verteidigungsministerium artiger USA-Zugriffssteuerungen durch den Gebrauch von Linux Security Modules (LSM) im Kern von Linux zu unterstützen. Es ist nicht ein Vertrieb von Linux, aber eher eine Reihe von Kernmodifizierungen und Benutzerraumwerkzeuge, die zum verschiedenen Vertrieb von Linux hinzugefügt werden können. Seine Architektur müht sich, Erzwingung von Sicherheitsentscheidungen von der Sicherheitspolitik selbst zu trennen, und rationalisiert das Volumen der wegen der Sicherheitspolitikerzwingung angeklagten Software. Die Schlüsselkonzepte, die SELinux unterliegen, können zu mehreren früheren Projekten von der USA-Staatssicherheitsagentur verfolgt werden.

Es ist in die Hauptstrecke Kern von Linux seit der Version 2.6 integriert worden.

Übersicht

USA-National Security Agency (NSA), der ursprüngliche primäre Entwickler von SELinux, hat die erste Version zur offenen Quellentwicklungsgemeinschaft unter dem GNU GPL am 22. Dezember 2000 veröffentlicht.

Die Software hat in die Hauptstrecke Kern von Linux 2.6.0-test3, veröffentlicht am 8. August 2003 verschmolzen. Andere bedeutende Mitwirkende schließen Network Associates, Secure Computing Corporation ein, hat Computerlösungen und Tresys Technologie Vertraut. Experimentelle Häfen der FLASK/TE Durchführung sind über das Projekt von TrustedBSD für FreeBSD und Darwin Betriebssysteme bereitgestellt worden.

Von NSA Sicherheitserhöhte Linux Mannschaft:

: "NSA Sicherheitserhöhter Linux ist eine Reihe von Flecken zum Kern von Linux und einige Dienstprogramme, um eine starke, flexible Architektur der obligatorischen Zugriffskontrolle (MAC) in die Hauptsubsysteme des Kerns zu vereinigen. Es stellt einen erhöhten Mechanismus zur Verfügung, die Trennung der auf Vertraulichkeits- und Integritätsvoraussetzungen gestützten Information geltend zu machen, der Drohungen des Herumbastelns und Umleitens von Anwendungssicherheitsmechanismen erlaubt, gerichtet zu werden, und die Beschränkung des Schadens ermöglicht, der durch böswillige oder fehlerhafte Anwendungen verursacht werden kann. Es schließt eine Reihe von Beispielsicherheitspolitikkonfigurationsdateien ein, die entworfen ist, um allgemeine Mehrzwecksicherheitsabsichten zu entsprechen."

(SELinux ist in die Reihe der Version 2.6 des Kerns von Linux integriert worden, und getrennte Flecke sind jetzt unnötig; der obengenannte ist ein historischer Kostenvoranschlag.)

Sicherheitserhöhter Linux führt den Fluss durch Fortgeschrittener Sicherheitskern (TASCHENFLASCHE), die in einige Versionen des Kerns von Linux mit mehreren Dienstprogrammen integriert ist, hat vorgehabt, den Wert obligatorischer Zugriffssteuerungen zur Gemeinschaft von Linux zu demonstrieren, und wie solche Steuerungen zu Linux hinzugefügt werden konnten. Solch ein Kern enthält architektonische Bestandteile prototyped im Glücksfall Betriebssystem. Diese stellen allgemeine Unterstützung zur Verfügung, um viele Arten von obligatorischen Zugriffskontrollpolicen, einschließlich derjenigen geltend zu machen, die auf den Konzepten der Typ-Erzwingung, Rolle-basierten Zugriffskontrolle und Mehrniveau-Sicherheit gestützt sind. TASCHENFLASCHE hat abwechselnd auf DTOS, einem Mach-abgeleiteten Verteilten Vertrauten Betriebssystem, sowie Vertrautem Mach, einem Forschungsprojekt von Vertrauten Informationssystemen basiert, die einen Einfluss auf das Design und die Durchführung von DTOS hatten.

Ein Linux Kern, der SELinux integriert, macht obligatorische Zugriffskontrolle-Policen geltend, die Benutzerprogramme und Systemserver zum minimalen Betrag des Vorzugs beschränken, den sie verlangen, um ihre Jobs zu tun. Das reduziert oder beseitigt die Fähigkeit dieser Programme und Dämonen, um wenn in Verlegenheit gebracht (über Pufferüberschwemmungen oder misconfigurations, zum Beispiel) Schaden zuzufügen. Dieser Beschränkungsmechanismus funktioniert unabhängig von den traditionellen Zugriffskontrollmechanismen von Linux. Es hat kein Konzept eines "Wurzel"-Überbenutzers, und teilt die wohl bekannten Mängel der traditionellen Sicherheitsmechanismen von Linux (wie eine Abhängigkeit von setuid/setgid Dualzahlen) nicht.

Die Sicherheit eines "unmodifizierten" Systems von Linux (ein System ohne SELinux) hängt von der Genauigkeit des Kerns, von allen privilegierten Anwendungen, und von jeder ihrer Konfigurationen ab. Ein Problem in irgendwelchen dieser Gebiete kann den Kompromiss des kompletten Systems erlauben. Im Gegensatz hängt die Sicherheit eines "modifizierten" Systems (gestützt auf einem SELinux) Kern in erster Linie von der Genauigkeit des Kerns und seiner Sicherheitspolitik-Konfiguration ab. Während Probleme mit der Genauigkeit oder Konfiguration von Anwendungen den beschränkten Kompromiss von individuellen Benutzerprogrammen und Systemdämonen erlauben können, stellen sie keine Bedrohung für die Sicherheit anderer Benutzerprogramme und Systemdämonen oder zur Sicherheit des Systems als Ganzes dar.

Von einer Purist-Perspektive stellt SELinux eine Hybride von Konzepten und Fähigkeiten zur Verfügung, die von obligatorischen Zugriffssteuerungen, obligatorischen Integritätssteuerungen, Rolle-basierter Zugriffskontrolle (RBAC) und Typ-Vollzugsarchitektur gezogen sind. Drittwerkzeuge ermöglichen, eine Vielfalt von Sicherheitspolicen zu bauen.

Benutzer, Policen und Sicherheitszusammenhänge

SELinux Benutzer und Rollen sind mit den wirklichen Systembenutzern und Rollen nicht verbunden. Für jeden aktuellen Benutzer oder Prozess teilt SELinux einen drei Schnur-Zusammenhang zu, der aus einer Rolle, Benutzernamen und Gebiet (oder Typ) besteht. Dieses System ist flexibler als normalerweise erforderlich: In der Regel teilen die meisten echten Benutzer denselben SELinux Benutzernamen, und die ganze Zugriffskontrolle wird durch das dritte Anhängsel, das Gebiet geführt. Umstand dafür, wenn dem Benutzer erlaubt wird, in ein bestimmtes Gebiet zu kommen, muss in den Policen konfiguriert werden. Der Befehl runcon berücksichtigt den Stapellauf eines Prozesses in einen ausführlich angegebenen Zusammenhang (Benutzer, Rolle und Gebiet), aber SELinux kann den Übergang bestreiten, wenn es durch die Politikkonfiguration nicht genehmigt wird.

Dateien, Netzhäfen und andere Hardware haben auch einen SELinux Zusammenhang, aus einem Namen, Rolle (selten verwendet), und Typ bestehend. Im Falle der Dateisysteme, zwischen Dateien und den Sicherheitszusammenhängen kartografisch darstellend, wird genannt etikettierend. Das Beschriften wird in Politikdateien definiert, aber kann auch manuell angepasst werden, ohne die Policen zu ändern. Über Hardware-Typen, wird zum Beispiel, bin_t (alle Dateien in der Mappe / Behälter) oder postgresql_port_t (Hafen von PostgreSQL, 5432) ganz ausführlich berichtet. Der SELinux Zusammenhang für ein entferntes Dateisystem kann ausführlich in der Gestell-Zeit angegeben werden. SELinux fügt hinzu, dass die-Z auf die Schale umschalten, befiehlt ls, ps, und einigen anderen, dem Sicherheitszusammenhang der Dateien oder des Prozesses erlaubend, gesehen zu werden.

Typische Politikregeln bestehen häufig aus der ausführlichen Erlaubnis; welche Gebiete der Benutzer besitzen muss, um bestimmte Handlungen mit dem gegebenen Ziel durchzuführen (gelesen, führen Sie oder im Falle des Netzhafens durch, binden Sie oder stehen Sie in Verbindung), und so weiter. Kompliziertere mappings sind auch möglich, Rollen und Sicherheitsniveaus einschließend.

Eine typische Politik besteht aus einem kartografisch darstellenden (das Beschriften) Datei, eine Regel-Datei und eine Schnittstelle-Datei, die den Bereichsübergang definieren. Diese drei Dateien müssen zusammen mit den SELinux Werkzeugen kompiliert werden, um eine einzelne Politikdatei zu erzeugen. Die resultierende Politikdatei kann in den Kern geladen werden, es aktiv machend. Das Laden und die Entleerung von Policen verlangen keinen Neustart. Die Politikdateien sind entweder Hand schriftlich oder können vom benutzerfreundlicheren SELinux Verwaltungswerkzeug erzeugt werden. Sie werden normalerweise in der permissiven Weise zuerst geprüft, wo Übertretungen geloggt, aber erlaubt werden. Das audit2allow Werkzeug kann später verwendet werden, um zusätzliche Regeln zu erzeugen, die die Politik erweitern, alle legitimen Tätigkeiten der Anwendung zu erlauben, die wird beschränkt.

Eigenschaften

Saubere Trennung der Politik von der Erzwingung
Bestimmte Politik verbindet
Unterstützung für Anwendungen, die die Politik fragen und Zugriffskontrolle (zum Beispiel, crond laufende Jobs im richtigen Zusammenhang) geltend machen
Unabhängig von spezifischen Policen und Politiksprachen
Unabhängig der spezifischen Sicherheit etikettieren Formate und Inhalt
Individuelle Etiketten und Steuerungen für Kerngegenstände und Dienstleistungen
Die Unterstützung für die Politik ändert
Getrennte Maßnahmen, um Systemintegrität (Bereichstyp) und Datengeheimnis (Mehrniveau-Sicherheit) zu schützen
Flexible Politik
Steuerungen über die Prozess-Initialisierung und das Erbe und die Programm-Ausführung
Steuerungen über Dateisysteme, Verzeichnisse, Dateien und offene Dateideskriptoren
Steuerungen über Steckdosen, Nachrichten und Netz verbinden
Steuerungen über den Gebrauch von "Fähigkeiten"
Versteckte Information über Zugriffsentscheidungen über den AVC (Geheimes Zugriffsvektor-Lager)

Gebrauch

SELinux kann potenziell kontrollieren, welchen Tätigkeiten für jeden Benutzer, Prozess und Dämon mit sehr genauen Spezifizierungen erlaubt wird. Jedoch wird es größtenteils verwendet, um Dämonen wie Datenbankmotoren oder Webserver zu beschränken, die klarer Datenzugang und Tätigkeitsrechte definiert haben. Ein beschränkter Dämon, der in Verlegenheit gebracht wird, wird so im Schaden beschränkt, dem es zufügen kann. Gewöhnlicher Benutzer geht häufig geführt im unbegrenzten Gebiet in einer Prozession, das nicht durch SELinux eingeschränkt ist, aber noch durch die klassischen Zugriffsrechte von Linux eingeschränkt ist.

Siehe auch: chcon,

restorecon,

restorecond,

runcon,

secon,

fixfiles,

setfiles,

load_policy,

booleans,

getsebool,

setsebool,

togglesebool

setenforce, load_policy

setfiles,

selinuxenabled, semodule, postüble-Lage-nochroot, check-selinux-installation, semodule_package, checkmodule, selinux-config-enforcing, selinuxenabled, selinux-policy-upgrade;

und auch: security_set_boolean

Gebrauch-Beispiel (um SELinux in der permissiven Weise zu stellen):

# setenforce 0

Durchführungen

SELinux ist mit der kommerziellen Unterstützung als ein Teil der Version 4 von Red Hat Enterprise Linux (RHEL) und aller zukünftigen Ausgaben verfügbar. Diese Anwesenheit wird auch in entsprechenden Versionen von CentOS widerspiegelt. Die unterstützte Politik in RHEL4 ist die ins Visier genommene Politik, die auf maximale Bequemlichkeit des Gebrauches zielt und so nicht so einschränkend ist, wie es sein könnte. Zukünftige Versionen von RHEL werden mehr Ziele in der ins Visier genommenen Politik haben, die einschränkendere Policen bedeuten wird.

In der freien Gemeinschaft unterstützter GNU/Linux Vertrieb war Fedora einer der frühsten Adoptierenden, einschließlich der Unterstützung dafür standardmäßig seit Fedora Core 2. Anderer Vertrieb schließt Unterstützung dafür wie Debian bezüglich der ätzen Ausgabe, Ubuntu bezüglich 8.04 Zähen Reihers, Gehärteten Gentoo und Gelben Hunds Linux ein.

Es wird auch in EnGarde Sicherer Linux unterstützt.

Bezüglich der Version 11.1 enthält openSUSE SELinux "grundlegender enablement". SUSE Linux Unternehmen 11 wird SELinux als eine "Technologievorschau" zeigen.

Es gab etwas Arbeit, um SELinux Pakete für Slackware zur Verfügung zu stellen, aber Entwicklung scheint, stagniert zu haben.

Es hat Arbeit an anderem Vertrieb wie Vertrauter Linux gegeben, aber etwas davon wurde wegen technischer Gründe aufgehört. (Die Vertraute Linux-Arbeit wurde aufgegeben, als SELinux erweiterte Dateiattribute gebraucht hat, die im JFFS2 filesystem ununterstützt sind.)

Die frühste Arbeit hat zum Standardisieren einer Annäherung zur Bestimmung von obligatorischen und dem eigenen Gutdünken überlassenen Zugriffssteuerungen (MAC und DAC) innerhalb eines UNIX befohlen (genauer, POSIX) Rechenumgebung kann der Staatssicherheitsagentur zugeschrieben werden hat UNIX (TRUSIX) Arbeitsgruppe Vertraut, die sich von 1987 bis 1991 getroffen hat und ein Regenbogen-Buch (#020A) veröffentlicht hat und ein formelles Modell erzeugt hat und Einschätzungsbeweis-Prototyp (#020B) vereinigt hat, der schließlich unveröffentlicht war. Es wurde von Chet Coates und Mario Tinto von Nationaler Computersicherheit des NSA Zentrum gesponsert, und von Dr Charles Testa und Bruce Wilner von Infosystems Technologie geführt (Grüngürtel, Maryland; später, Fall-Kirche, Virginia), die entscheidenden Architekten des TRUSIX-Projektes und Mitglieder seines Modellierenden Unterausschusses - Steve Bunch, Dr Frank Knowles, Dr J. Eric Roskos, Larry Wehr und Bruce Wilner. Ihre Anstrengungen, besonders als Kritiker der weniger technisch tiefen Arbeit des TRUSIX Unterausschusses der Zugriffsberechtigungsliste (ACL), überleben im IEEE POSIX 1003.6" Sicherheitserweiterungen für die tragbare Umgebungen" Betriebssystemspezifizierung.

Andere Systeme

SELinux vertritt eine von mehreren möglichen Annäherungen an das Problem, die Handlungen einzuschränken, die installierte Software nehmen kann.

Das System von AppArmor nimmt allgemein eine ähnliche Annäherung an SELinux. Ein wichtiger Unterschied ist, dass AppArmor Dateisystemgegenstände durch den Pfadnamen statt inode identifiziert. Das bedeutet, dass, zum Beispiel, eine Datei, die unzugänglich ist, zugänglich unter AppArmor werden kann, wenn eine harte Verbindung dazu geschaffen wird, während SELinux Zugang durch die kürzlich geschaffene harte Verbindung bestreiten würde. Andererseits können Daten, der in SELinux unzugänglich ist, zugänglich werden, wenn Anwendungen die Datei durch das Ersetzen davon durch eine neue Version - eine oft verwendete Technik aktualisieren - während AppArmor fortsetzen würde, Zugang zu den Daten zu bestreiten. In beiden Fällen vermeidet eine Verzug-Politik "keines Zugangs" das Problem.

SELinux und AppArmor unterscheiden sich auch bedeutsam darin, wie sie verwaltet werden, und wie sie ins System integrieren.

Die Isolierung von Prozessen kann auch durch Mechanismen wie Virtualisierung vollbracht werden; das OLPC-Projekt, zum Beispiel, in seiner ersten Durchführung sandboxed individuelle Anwendungen im Leichtgewichtler Vservers.

Siehe auch

AppArmor
Grsecurity
Mehrniveau-Sicherheit
Rule Set Based Access Control (RSBAC)
Vereinfachter obligatorischer Zugriffskontrollkern
Solaris hat Erweiterungen vertraut
Tomoyo
TrustedBSD

Siehe auch:
Debian

Zagreb / Lorbeer und zäh Impressum & Datenschutz