SELinux-Konzepte

Sehen Sie sich diese Seite an, um sich mit den Konzepten von SELinux 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 von dem bekannten DAC-System (Discretionary Access Control) von Linux. In einem DAC-System existiert ein Eigentumskonzept, bei dem ein Eigentümer einer bestimmten Ressource die damit verbundenen Zugriffsberechtigungen steuert. Dies ist im Allgemeinen grobkörnig und unterliegt einer unbeabsichtigten Rechteausweitung. Ein MAC-System konsultiert jedoch eine zentrale Autorität für eine Entscheidung über alle Zugriffsversuche.

SELinux wurde als Teil des Linux Security Module (LSM)-Frameworks implementiert, das verschiedene Kernel-Objekte und darauf ausgeführte vertrauliche Aktionen erkennt. An dem Punkt, an dem jede dieser Aktionen ausgeführt werden würde, wird eine LSM-Hook-Funktion aufgerufen, um zu bestimmen, ob die Aktion auf der Grundlage der in einem undurchsichtigen Sicherheitsobjekt gespeicherten Informationen dafür zugelassen werden sollte oder nicht. SELinux bietet eine Implementierung für diese Hooks und die Verwaltung dieser Sicherheitsobjekte, die mit seiner eigenen Richtlinie kombiniert werden, um die Zugriffsentscheidungen zu bestimmen.

Zusammen mit anderen Android-Sicherheitsmaßnahmen schränkt die Zugriffskontrollrichtlinie von Android den potenziellen Schaden durch kompromittierte Computer und Konten erheblich ein. Die Verwendung von Tools wie den diskretionären und obligatorischen Zugriffskontrollen von Android gibt Ihnen eine Struktur, um sicherzustellen, dass Ihre Software nur mit der minimalen Berechtigungsstufe 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 eine obligatorische Zugriffssteuerung (MAC) als Umbrella über herkömmlichen DAC-Umgebungen (Discretionary Access Control). Beispielsweise muss Software normalerweise als Root-Benutzerkonto ausgeführt werden, um auf Raw-Block-Geräte zu schreiben. Wenn in einer traditionellen DAC-basierten Linux-Umgebung der Root-Benutzer kompromittiert wird, kann dieser Benutzer auf jedes Raw-Block-Gerät schreiben. SELinux kann jedoch verwendet werden, um diese Geräte zu kennzeichnen, sodass der Prozess, dem das Root-Privileg zugewiesen wurde, nur auf die schreiben kann, die in der zugehörigen Richtlinie angegeben sind. 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, sie mit SELinux anzugehen, finden Sie unter Anwendungsfälle .

Durchsetzungsstufen

SELinux kann in verschiedenen Modi implementiert werden:

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

Diese Auswahl ist binär und bestimmt, ob Ihre Richtlinie Maßnahmen ergreift oder Ihnen lediglich ermöglicht, potenzielle Fehler zu erfassen. Permissive ist besonders nützlich während der Implementierung.

Typen, Attribute und Regeln

Android verlässt sich für seine Richtlinie auf die Komponente Type Enforcement (TE) von SELinux. Das bedeutet, dass allen Objekten (z. B. Datei, Prozess oder Socket) ein Typ zugeordnet ist. Beispielsweise hat eine App standardmäßig den Typ untrusted_app . Bei einem Prozess wird sein Typ auch als seine 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. eine Datei, ein Verzeichnis, ein symbolischer Link, ein Socket) und die verschiedenen Zugriffsarten für jede Klasse werden durch Berechtigungen dargestellt. Beispielsweise existiert für die file die Berechtigung open . Während Typen und Attribute im Rahmen der Android SELinux-Richtlinie regelmäßig aktualisiert werden, werden Berechtigungen und Klassen statisch definiert und selten im Rahmen einer neuen Linux-Version aktualisiert.

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

  • Quelle – Der Typ (oder das Attribut) des Subjekts der Regel. Wer beantragt den Zugriff?
  • Ziel – Der Typ (oder das Attribut) des Objekts. Wozu wird der Zugriff angefordert?
  • Klasse – Die Art des Objekts (z. B. Datei, Socket), auf das zugegriffen wird.
  • Berechtigungen – Die Operation (oder Gruppe von Operationen) (z. B. Lesen, Schreiben), die 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 Typen für Apps. Beispielsweise wird „ isolated_app “ für App-Dienste mit „ isolatedProcess=true “ in ihrem Manifest verwendet. Anstatt die Regel für beide Typen zu wiederholen, verwendet Android ein Attribut namens appdomain für alle Typen, die Apps abdecken:

# 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 Statistik darauf stat . Um die Regeldefinition zu vereinfachen, stellt Android eine Reihe von Makros bereit, um die häufigsten Fälle zu behandeln. Um beispielsweise die fehlenden Berechtigungen wie open , 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 . Makros sollten wann immer möglich verwendet werden, um die Wahrscheinlichkeit von Fehlern aufgrund von Verweigerungen verwandter Berechtigungen zu verringern.

Sobald ein Typ definiert ist, muss er mit der Datei oder dem Prozess, den er darstellt, verknüpft werden. Siehe Implementieren von SELinux für weitere Einzelheiten darüber, wie diese Zuordnung erfolgt. Weitere Informationen zu Regeln finden Sie im SELinux-Notebook .

Sicherheitskontext und Kategorien

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

  • Isolieren Sie die App-Daten vom Zugriff durch eine andere App,
  • Isolieren Sie die App-Daten von einem physischen Benutzer zu einem anderen.

Spezifität

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

  • Die Mehrzahl der Richtlinien in AOSP wird mit 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 definierte Benutzer ist u . Bei Bedarf werden physische Benutzer mithilfe des Kategorienfelds eines Sicherheitskontexts dargestellt.
  • SELinux- Rollen und rollenbasierte Zugriffssteuerung (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.
  • Boolesche SELinux-Werte werden nicht verwendet. Sobald die Richtlinie für ein Gerät erstellt wurde, hängt sie nicht vom Zustand des Geräts ab. Dies vereinfacht das Auditing und Debugging von Richtlinien.