SELinux-Konzepte

Lesen Sie diese Seite, um sich mit den Konzepten von SELinux vertraut zu machen.

Obligatorische Zugriffssteuerung

Security Enhanced Linux (SELinux) ist ein obligatorisches MAC-System (Access Control) für das Betriebssystem Linux. Als MAC-System unterscheidet es sich von der ein vertrautes DAC-System (Discretionary Access Control). In einem DAC-System wird der Inhaberschaft existiert, wobei ein Inhaber einer bestimmten Ressource den Zugriff kontrolliert Berechtigungen, die damit verknüpft sind. Diese sind normalerweise grob und subjektiv unbeabsichtigte Rechteausweitung. Ein MAC-System konsultiert jedoch ein zentrales Entscheidungsbefugnis über Zugriffsversuche.

SELinux wurde als Teil des Linux Security Module (LSM) implementiert. Framework, das verschiedene Kernel-Objekte und vertrauliche Aktionen erkennt die bei ihnen ausgeführt wurden. Zu dem Zeitpunkt, an dem jede dieser Aktionen wird eine LSM-Hook-Funktion aufgerufen, um zu ermitteln, sollte basierend auf den in einer opaken Security Objects. SELinux bietet eine Implementierung für diese Hooks und Sicherheitsobjekte, die in Kombination mit einer eigenen Richtlinie verwaltet werden, Entscheidungen über den Zugriff treffen.

Neben anderen Sicherheitsmaßnahmen von Android bietet die die potenziellen Schäden durch infizierte Computer und Konten. Verwendung von Tools wie den frei zugänglichen und obligatorischen Zugriffsrechten von Android Kontrollmöglichkeiten gibt Ihnen eine Struktur, mit der Sie sicherstellen, dass Ihre Software nur auf Minimum ausgeführt wird. Berechtigungsstufe. Dadurch werden die Auswirkungen von Angriffen abgeschwächt Wahrscheinlichkeit, dass fehlerhafte Prozesse Daten überschreiben oder sogar übertragen.

In Android 4.3 und höher bietet SELinux eine obligatorische Zugriffssteuerung (MAC) eine höhere Priorität als herkömmliche DAC-Umgebungen. Für Instanz muss die Software in der Regel als Root-Nutzerkonto ausgeführt werden, um in die Rohdaten schreiben zu können. Geräte zu blockieren. Wenn der Root-Nutzer in einer herkömmlichen DAC-basierten Linux-Umgebung gefährdet ist, dass der Nutzer auf jedem Rohblockgerät schreiben kann. Sie können jedoch Diese Geräte können mit SELinux gekennzeichnet werden, sodass der Prozess kann nur in die in der verknüpften Richtlinie angegebenen Daten geschrieben werden. In dieser kann der Prozess keine Daten und Systemeinstellungen außerhalb des bestimmte RAW-Block-Geräte.

Siehe Anwendungsfälle finden Sie weitere Beispiele für Bedrohungen und Möglichkeiten, ihnen mit SELinux zu begegnen.

Durchsetzungsstufen

SELinux kann in verschiedenen Modi implementiert werden:

• Moderat: 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 nur um potenzielle Fehler zu sammeln. „Moderat“ ist besonders nützlich bei Implementierung.

Typen, Attribute und Regeln

Android nutzt die TE-Komponente (Type Enforcement) von SELinux für seine . Das bedeutet, dass alle Objekte (wie Datei, Prozess oder Socket) eine type, der ihnen zugeordnet ist. Standardmäßig wird eine App hat den Typ untrusted_app. Bei einem Prozess ist sein Typ ebenfalls auch als Domain bezeichnet. Es ist möglich, einen Typ mit einem oder viele attributes. Attribute sind nützlich, um auf mehrere Typen zu verweisen. aus.

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 repräsentiert. Für die Klasse ist beispielsweise die Berechtigung open vorhanden. file. Typen und Attribute werden zwar regelmäßig im Rahmen die Android SELinux-Richtlinie, Berechtigungen und Klassen statisch definiert und wird selten im Rahmen einer neuen Linux-Version aktualisiert.

Eine Richtlinienregel hat das folgende Format: allow source target:class permissions; Dabei gilt:

• Quelle: Typ (oder Attribut) des Subjekts der Regel. Wer fordert den Zugriff an?
• Ziel: Der Typ (oder das Attribut) des Objekts. Welchen Zugriff wird angefordert?
• Klasse: Die Art des Objekts (z.B. Datei, Socket), auf das zugegriffen wird.
• Berechtigungen: Der durchgeführte Vorgang oder die Gruppe von Vorgängen (z.B. Lese- oder Schreibvorgänge).

Hier ist ein Beispiel für eine Regel:

allow untrusted_app app_data_file:file { read write };

Dies besagt, dass Apps Dateien mit dem Label app_data_file Es gibt noch andere Typen von Apps. Für Instanzen haben, wird isolated_app für Anwendungsdienste mit isolatedProcess=true. Anstatt die für beide Typen gilt, verwendet Android ein Attribut namens appdomain für alle App-Typen:

# 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, ist dieser Name automatisch auf die Liste der Domains oder Typen erweitert, die mit der . Einige wichtige Attribute sind:

• domain – Attribut, das mit allen Prozesstypen verknüpft ist
• file_type – Attribut, das allen Dateitypen zugeordnet ist.

Makros

Insbesondere für den Dateizugriff gibt es viele Arten von Berechtigungen, zu berücksichtigen. Beispielsweise reicht die Berechtigung read nicht aus, um die Datei oder stat dazu aufrufen. Zur Vereinfachung der Regeldefinition stellt eine Reihe von Makros für die häufigsten Fälle bereit. Um beispielsweise um die fehlenden Berechtigungen wie z. B. open aufzunehmen, die Regel oben wie folgt umformuliert werden:

allow appdomain app_data_file:file rw_file_perms;

Weitere Informationen finden Sie in der global_macros. und te_macros -Dateien finden Sie weitere Beispiele für nützliche Makros. Nach Möglichkeit sollten Makros verwendet werden um die Wahrscheinlichkeit von Fehlern aufgrund von Ablehnungen Berechtigungen.

Nachdem ein Typ definiert wurde, muss er der Datei oder dem Prozess zugeordnet werden. die sie repräsentiert. Siehe SELinux implementieren . Weitere Informationen zur finden Sie in der SELinux-Notebook.

Sicherheitskontext und ‐kategorien

Beim Debuggen von SELinux-Richtlinien oder Labeling-Dateien (über file_contexts oder ls -Z) in einem Sicherheitskontext (auch als Label bezeichnet). Für Beispiel: u:r:untrusted_app:s0:c15,c256,c513,c768 Ein Sicherheitskontext hat folgendes Format: user:role:type:sensitivity[:categories] In der Regel können Sie die user-, role- und sensitivity-Felder einer Kontext (siehe Spezifität). Das type wird im vorherigen Abschnitt erläutert. categories gehören zu das Multi-Level Security (MLS) in SELinux unterstützt. Seit Android S werden Kategorien verwendet, um:

• die App-Daten für den Zugriff durch andere Apps zu isolieren,
• Die App-Daten von einem physischen Nutzer zum anderen isolieren.

Spezifität

Android verwendet nicht alle von SELinux bereitgestellten Funktionen. Beim Lesen externe Dokumentation erhalten Sie diese 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-Nutzer werden nicht verwendet. Die einzige benutzerdefinierte u Bei Bedarf werden physische Nutzer mithilfe des Felds „Kategorien“ eines Sicherheitskontexts dargestellt.
• SELinux-Rollen und rollenbasierte Zugriffssteuerung (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-Vertraulichkeiten werden nicht verwendet. Die standardmäßige Empfindlichkeit für s0 ist immer festgelegt.
• Die booleschen Werte für SELinux werden nicht verwendet. Sobald die Richtlinie für ein Gerät erstellt wurde, hängt nicht vom Status des Geräts ab. Dies vereinfacht die Richtlinien prüfen und Fehler beheben.