Diese Seite wurde von der Cloud Translation API übersetzt.

SELinux-Konzepte

Sehen Sie sich diese Seite an, um sich mit den SELinux-Konzepten vertraut zu machen.

Obligatorische Zugangskontrolle

Security Enhanced Linux (SELinux) ist ein obligatorisches Zugriffskontrollsystem (MAC) für das Linux-Betriebssystem. Als MAC-System unterscheidet es sich vom bekannten Discretionary Access Control (DAC)-System von Linux. In einem DAC-System gibt es ein Eigentumskonzept, bei dem ein Eigentümer einer bestimmten Ressource die damit verbundenen Zugriffsberechtigungen kontrolliert. Dies ist im Allgemeinen grobkörnig und unterliegt einer unbeabsichtigten Rechteausweitung. Ein MAC-System hingegen konsultiert eine zentrale Instanz zur Entscheidung über alle Zugriffsversuche.

SELinux wurde als Teil des Linux Security Module (LSM)-Frameworks implementiert, das verschiedene Kernel-Objekte und sensible Aktionen erkennt, die auf ihnen ausgeführt werden. An dem Punkt, an dem jede dieser Aktionen ausgeführt wird, wird eine LSM-Hook-Funktion aufgerufen, um anhand der in einem undurchsichtigen Sicherheitsobjekt gespeicherten Informationen zu bestimmen, ob die Aktion zulässig sein soll oder nicht. SELinux bietet eine Implementierung für diese Hooks und die Verwaltung dieser Sicherheitsobjekte, die in Kombination mit seiner eigenen Richtlinie die Zugriffsentscheidungen bestimmen.

Zusammen mit anderen Android-Sicherheitsmaßnahmen begrenzt die Zugriffskontrollrichtlinie von Android den potenziellen Schaden kompromittierter Computer und Konten erheblich. Durch die Verwendung von Tools wie den diskretionären und obligatorischen Zugriffskontrollen von Android erhalten Sie eine Struktur, die sicherstellt, dass Ihre Software nur mit der Mindestberechtigungsstufe ausgeführt wird. Dies mildert die Auswirkungen von Angriffen und verringert die Wahrscheinlichkeit, dass fehlerhafte Prozesse Daten überschreiben oder sogar übertragen.

In Android 4.3 und höher bietet SELinux einen MAC-Schutz (Mandatory Access Control) gegenüber herkömmlichen DAC-Umgebungen (Discretionary Access Control). Beispielsweise muss Software normalerweise als Root-Benutzerkonto ausgeführt werden, um auf Raw-Block-Geräte schreiben zu können. Wenn in einer herkömmlichen DAC-basierten Linux-Umgebung der Root-Benutzer kompromittiert wird, kann dieser Benutzer auf jedes Raw-Block-Gerät schreiben. Allerdings kann SELinux verwendet werden, um diese Geräte zu kennzeichnen, sodass der Prozess, dem die Root-Berechtigung zugewiesen wurde, nur auf die in der zugehörigen Richtlinie angegebenen Geräte schreiben kann. Auf diese Weise kann der Prozess keine Daten und Systemeinstellungen außerhalb des spezifischen Rohblockgeräts überschreiben.

Weitere Beispiele für Bedrohungen und Möglichkeiten, diese mit SELinux zu bekämpfen, finden Sie unter Anwendungsfälle .

Durchsetzungsstufen

SELinux kann in verschiedenen Modi implementiert werden:

Zulässig – Die SELinux-Sicherheitsrichtlinie wird nicht erzwungen, sondern nur protokolliert.
Durchsetzen – Die Sicherheitsrichtlinie wird durchgesetzt und protokolliert. Fehler werden als EPERM-Fehler angezeigt.

Diese Auswahl ist binär und bestimmt, ob Ihre Richtlinie Maßnahmen ergreift oder Ihnen lediglich die Erfassung potenzieller Fehler ermöglicht. Permissiv ist besonders bei der Implementierung nützlich.

Typen, Attribute und Regeln

Android verlässt sich bei seiner Richtlinie auf die Type Enforcement (TE)-Komponente von SELinux. Dies bedeutet, dass allen Objekten (z. B. Dateien, Prozessen oder Sockets) ein Typ zugeordnet ist. Beispielsweise hat eine App standardmäßig den Typ untrusted_app . Bei einem Prozess wird sein Typ auch als Domäne bezeichnet. Es ist möglich, einen Typ mit einem oder mehreren Attributen zu versehen. Attribute sind nützlich, um auf mehrere Typen gleichzeitig zu verweisen.

Objekte werden Klassen zugeordnet (z. B. einer Datei, einem Verzeichnis, einem symbolischen Link, einem Socket) und die verschiedenen Zugriffsarten für jede Klasse werden durch Berechtigungen dargestellt. Beispielsweise existiert die Berechtigung open für die file . Während Typen und Attribute im Rahmen der Android SELinux-Richtlinie regelmäßig aktualisiert werden, werden Berechtigungen und Klassen statisch definiert und im Rahmen einer neuen Linux-Version selten aktualisiert.

Eine Richtlinienregel hat die folgende Form: allow source target : class permissions ; Wo:

Quelle – Der Typ (oder das Attribut) des Subjekts der Regel. Wer beantragt den Zugang?
Ziel – Der Typ (oder das Attribut) des Objekts. Wozu wird der Zugang beantragt?
Klasse – Die Art des Objekts (z. B. Datei, Socket), auf das zugegriffen wird.
Berechtigungen – Der Vorgang (oder die Reihe von Vorgängen) (z. B. Lesen, Schreiben), der ausgeführt wird.

Ein Beispiel für eine Regel ist:

allow untrusted_app app_data_file:file { read write };

Dies besagt, dass Apps Dateien mit der Bezeichnung app_data_file lesen und schreiben dürfen. Es gibt andere Arten von Apps. Beispielsweise wird isolated_app für App-Dienste verwendet, deren Manifest isolatedProcess=true enthält. Anstatt die Regel für beide Typen zu wiederholen, verwendet Android für alle Typen, die Apps abdecken, ein Attribut namens appdomain :

# Associate the attribute appdomain with the type untrusted_app.
typeattribute untrusted_app, appdomain;

# Associate the attribute appdomain with the type isolated_app.
typeattribute isolated_app, appdomain;

allow appdomain app_data_file:file { read write };

Wenn eine Regel geschrieben wird, die einen Attributnamen angibt, wird dieser Name automatisch auf die Liste der Domänen oder Typen erweitert, die dem Attribut zugeordnet sind. Einige bemerkenswerte Attribute sind:

domain – Attribut, das allen Prozesstypen zugeordnet ist,
file_type – Attribut, das allen Dateitypen zugeordnet ist.

Makros

Insbesondere für den Dateizugriff sind viele Arten von Berechtigungen zu berücksichtigen. Beispielsweise reicht die read nicht aus, um die Datei zu öffnen oder stat darauf aufzurufen. Um die Regeldefinition zu vereinfachen, stellt Android eine Reihe von Makros zur Verfügung, mit denen die häufigsten Fälle behandelt werden können. Um beispielsweise die fehlenden Berechtigungen wie open einzuschließen, könnte die obige Regel wie folgt umgeschrieben werden:

allow appdomain app_data_file:file rw_file_perms;

Weitere Beispiele für nützliche Makros finden Sie in den Dateien global_macros und te_macros . Wann immer möglich sollten Makros verwendet werden, um die Wahrscheinlichkeit von Fehlern aufgrund der Verweigerung entsprechender Berechtigungen zu verringern.

Sobald ein Typ definiert ist, muss er der Datei oder dem Prozess zugeordnet werden, die er darstellt. Weitere Einzelheiten zur Durchführung dieser Zuordnung finden Sie unter „Implementieren von SELinux“ . Weitere Informationen zu Regeln finden Sie im SELinux Notebook .

Sicherheitskontext und -kategorien

Beim Debuggen von SELinux-Richtlinien oder beim Kennzeichnen von Dateien (über file_contexts oder beim Aufrufen ls -Z ) stoßen Sie möglicherweise auf einen Sicherheitskontext (auch als label bezeichnet). Zum Beispiel: u:r:untrusted_app:s0:c15,c256,c513,c768 . Ein Sicherheitskontext hat das Format: user:role:type:sensitivity[:categories] . Normalerweise können Sie die user , role und sensitivity eines Kontexts ignorieren (siehe Spezifität ). Das type wird im vorherigen Abschnitt erläutert. categories sind Teil der Multi-Level Security (MLS) -Unterstützung in SELinux. Seit Android S werden Kategorien verwendet, um:

Isolieren Sie die App-Daten vor dem Zugriff durch eine andere App.
Isolieren Sie die App-Daten von einem physischen Benutzer zum anderen.

Spezifität

Android nutzt nicht alle von SELinux bereitgestellten Funktionen. Beachten Sie beim Lesen externer Dokumentation die folgenden Punkte:

Die meisten Richtlinien in AOSP werden mithilfe der Kernel Policy Language definiert. Es gibt einige Ausnahmen für die Verwendung der Common Intermediate Language (CIL).
SELinux- Benutzer werden nicht verwendet. Der einzige vom Benutzer definierte ist u . Bei Bedarf werden physische Benutzer mithilfe des Kategorienfelds eines Sicherheitskontexts dargestellt.
SELinux- Rollen und Role-Based Access Control (RBAC) werden nicht verwendet. Es werden zwei Standardrollen definiert und verwendet: r für Subjekte und object_r für Objekte.
SELinux- Empfindlichkeiten werden nicht verwendet. Die Standard- s0 Empfindlichkeit ist immer eingestellt.
SELinux-Boolesche Werte werden nicht verwendet. Sobald die Richtlinie für ein Gerät erstellt wurde, ist sie nicht mehr vom Zustand des Geräts abhängig. Dies vereinfacht die Prüfung und Fehlerbehebung von Richtlinien.