SELinux-Richtlinie schreiben

Das Open-Source-Projekt von Android (AOSP) bietet eine solide Basisrichtlinie für Apps und Dienste, die auf allen Android-Geräten verfügbar sind. Beitragende von AOSP verfeinern diese Richtlinie regelmäßig. Die Kernrichtlinie wird erwartet die etwa 90 bis 95% der endgültigen On-Device-Richtlinien mit gerätespezifischen Anpassungen, die die verbleibenden 5 bis 10 % ausmachen. In diesem Artikel geht es um wie Sie gerätespezifische Richtlinien erstellen einige Fallstricke, die Sie vermeiden sollten.

Gerät aktivieren

Gehen Sie beim Verfassen einer gerätespezifischen Richtlinie wie folgt vor:

Im moderaten Modus ausführen

Wenn sich ein Gerät befindet Moderation Ablehnungen werden protokolliert, aber nicht erzwungen. Der Moderationsmodus ist wichtig für zwei Gründe:

  • Der Modus „Moderat“ sorgt dafür, dass die Richtlinienerstellung andere Personen nicht frühzeitig verzögert. die Geräte aufrufen.
  • Eine erzwungene Ablehnung kann andere Ablehnungen verschleiern. Beispiel: Dateizugriff beinhaltet normalerweise eine Verzeichnissuche, Öffnen der Datei und anschließendes Lesen von Dateien. In wird nur die Verzeichnissuche abgelehnt. Moderat wird sichergestellt, dass alle Ablehnungen erkannt werden.

Der einfachste Weg, ein Gerät in den mäßigen Modus zu versetzen, ist die Verwendung der kernel-Befehl Zeile. Dies kann der Datei BoardConfig.mk des Geräts hinzugefügt werden: platform/device/<vendor>/<target>/BoardConfig.mk. Nachdem Sie die Befehlszeile geändert haben, führen Sie make clean aus, dann make bootimage und flashen Sie das neue Boot-Image.

Bestätigen Sie anschließend den moderaten Modus mit:

adb shell getenforce

Zwei Wochen sind angemessen, um sich in den globalen mäßigen Modus zu bewegen. Nachdem Sie die meisten Ablehnungen behoben haben, wechseln Sie wieder in den erzwungenen Modus und sofort auftretende Fehler zu beheben. Domains, die immer noch Ablehnungen oder Dienste generieren kann bei intensiver Entwicklung vorübergehend in den mäßigen Modus gesetzt werden, um sie so schnell wie möglich wieder in den Erzwingungsmodus zu versetzen.

Frühzeitig erzwingen

Im Erzwingenmodus werden Ablehnungen sowohl protokolliert als auch erzwungen. Es ist ein bester um das Gerät so früh wie möglich in den erzwungenen Modus zu versetzen. Warten auf Das Erstellen und Durchsetzen gerätespezifischer Richtlinien führt häufig zu einem fehlerhaften Produkt und schlechte User Experience ausmacht. Beginnen Sie früh genug, um sich Dogfooding und eine vollständige Testabdeckung der Funktionen in der realen Nutzung sicherstellen. Wird gestartet und stellt sicher, dass Sicherheitsbedenken bei Designentscheidungen getroffen werden. Umgekehrt kann das Gewähren Berechtigungen, die ausschließlich auf beobachteten Ablehnungen basieren, ist ein unsicherer Ansatz. Verwenden Zeit, das Gerät zu überprüfen und Fehler zu melden die nicht zulässig sein sollten.

Vorhandene Richtlinie entfernen oder löschen

Es gibt eine Reihe von guten Gründen, Scratch auf einem neuen Gerät durchgeführt. Dazu gehören:

Ablehnungen von Hauptdiensten beheben

Bei Ablehnungen, die von Hauptdiensten generiert werden, erfolgt normalerweise eine Dateikennzeichnung. Beispiel:

avc: denied { open } for pid=1003 comm=”mediaserver” path="/dev/kgsl-3d0”
dev="tmpfs" scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0
tclass=chr_file permissive=1
avc: denied { read write } for pid=1003 name="kgsl-3d0" dev="tmpfs"
scontext=u:r:mediaserver:s0
tcontext=u:object_r:device:s0 tclass=chr_file permissive=1

durch die richtige Kennzeichnung von /dev/kgsl-3d0 vollständig adressiert wird. In In diesem Beispiel ist tcontext device. Dies stellt eine Standardkontext, bei dem alles in /dev das Objekt „ Gerät“ beginnen, es sei denn, es wird ein spezifischeres Label zugewiesen. Einfach zu akzeptieren die Ausgabe von audit2allow zu einer falschen und zu moderaten Regelung führen.

Um diese Art von Problem zu lösen, geben Sie der Datei eine spezifischere Bezeichnung, die dieser Fall ist <ph type="x-smartling-placeholder"></ph> gpu_device. Es sind keine weiteren Berechtigungen erforderlich, da die <ph type="x-smartling-placeholder"></ph> Mediaserver verfügt bereits über die erforderlichen Berechtigungen in der Hauptrichtlinie, um auf den gpu_device.

Bei anderen gerätespezifischen Dateien, die mit den in den Kernrichtlinie:

Im Allgemeinen ist es falsch, Berechtigungen für Standardlabels zu gewähren. Viele davon Berechtigungen werden nicht zugelassen von neverallow-Regeln, aber auch wenn sie nicht ausdrücklich untersagt sind, empfiehlt es sich, eine spezifische .

Neue Dienste und Adresse kennzeichnen Ablehnungen

Von Init gestartete Dienste müssen in ihren eigenen SELinux-Domains ausgeführt werden. Die Im folgenden Beispiel wird der Dienst "foo" in seiner eigenen SELinux-Domain platziert und Berechtigungen.

Der Dienst wird im init.device.rc-Datei als:

service foo /system/bin/foo
    class core
  1. Neue Domain „foo“ erstellen

    Datei erstellen device/manufacturer/device-name/sepolicy/foo.te mit folgendem Inhalt:

    # foo service
type foo, domain;
type foo_exec, exec_type, file_type;

init_daemon_domain(foo)

    Dies ist die ursprüngliche Vorlage für die foo-SELinux-Domain, an die Sie Regeln hinzufügen, die auf den spezifischen Vorgängen basieren, die von der ausführbaren Datei ausgeführt werden.

  2. Label /system/bin/foo

    Folgendes hinzufügen zu device/manufacturer/device-name/sepolicy/file_contexts:

    /system/bin/foo   u:object_r:foo_exec:s0

    Dadurch wird sichergestellt, dass die ausführbare Datei ordnungsgemäß beschriftet ist, sodass SELinux das in der richtigen Domain zu finden.

  3. Erstellen und flashen Sie die Boot- und System-Images.
  4. Verfeinern Sie die SELinux-Regeln für die Domain.

    Verwenden Sie Ablehnungen, um die erforderlichen Berechtigungen zu ermitteln. Die audit2allow liefert gute Richtlinien, sollte aber nur als Grundlage für Richtlinienverstöße verwendet werden. beim Schreiben. Kopieren Sie nicht einfach die Ausgabe.

Zurück in den erzwungenen Modus wechseln

Im Modus „Weniger strikt“ ist die Fehlerbehebung möglich, Sie wechseln jedoch zurück zum erzwungenen und versuchen Sie, dort zu bleiben.

Häufige Fehler

Hier sind ein paar Lösungen für häufige Fehler beim Verfassen von Texten. gerätespezifischen Richtlinien.

Übermäßige Negation

Mit der folgenden Beispielregel wird die Haustür verriegelt, während die Fenster geöffnet:

allow { domain -untrusted_app } scary_debug_device:chr_file rw_file_perms

Der Sinn ist klar: Mit Ausnahme von Drittanbieter-Apps haben möglicherweise alle Nutzer Zugriff auf das Debugging .

Die Regel ist in mehrfacher Hinsicht fehlerhaft. Ausschluss von untrusted_app ist einfach zu umgehen, da alle Anwendungen optional Dienste in der isolated_app-Domain. Gleiches gilt, wenn neue Domains für Drittanbieter-Apps werden AOSP hinzugefügt, haben sie auch Zugriff auf scary_debug_device. Die Regel ist zu moderate. Die meisten Domains profitieren nicht davon, auf dieses Debugging-Tool zugreifen können. Die Regel hätte geschrieben werden sollen, dass nur die zugriffsbedürftigen Domains.

Debugging von Features in der Produktion

Debug-Funktionen sollten weder in Produktions-Builds vorhanden sein noch .

Die einfachste Alternative besteht darin, die Debug-Funktion nur zuzulassen, wenn SELinux bei eng/userdebug-Builds deaktiviert, z. B. adb root und adb shell setenforce 0.

Eine weitere sichere Alternative besteht darin, <ph type="x-smartling-placeholder"></ph> userdebug_or_eng verwenden.

Explosion der Richtliniengröße

Charakterisierung von SEAndroid-Richtlinien in der Wildnis beschreibt einen beunruhigenden Trend bei der zunehmenden Anpassung von Geräterichtlinien. Die gerätespezifische Richtlinie sollte 5 bis 10% der gesamten auf einem Gerät. Anpassungen im Bereich über 20%umfassen mit hoher Wahrscheinlichkeit über privilegierten Domains und Richtlinie in Bezug auf inaktive Nutzer.

Überflüssige Richtlinie:

  • Doppelte Reaktion auf den Arbeitsspeicher, während die Richtlinie auf der Ramdisk in den Kernel-Arbeitsspeicher geladen.
  • Vergeudet Speicherplatz, indem ein größeres Boot-Image erforderlich ist.
  • Wirkt sich auf die Suchzeiten der Laufzeitrichtlinie aus.

Das folgende Beispiel zeigt zwei Geräte, bei denen die 50% und 40% der On-Device-Richtlinie aus. Umformulierung der Richtlinie brachte erhebliche Sicherheitsverbesserungen ohne Verlust der Funktionalität. wie unten dargestellt. (Die AOSP-Geräte Shamu und Flounder sind zum Vergleich enthalten.)

Abbildung 1: Vergleich der gerätespezifischen Richtliniengröße nach der Sicherheitsprüfung.

Abbildung 1: Vergleich von gerätespezifischen Richtliniengröße nach der Sicherheitsprüfung.

In beiden Fällen wurde die Richtlinie erheblich reduziert, von Berechtigungen. Die Verkleinerung der Richtlinie ist fast vollständig auf die Entfernung unnötige Berechtigungen. Viele davon waren wahrscheinlich Regeln, die audit2allow, die wahllos der Richtlinie hinzugefügt wurden. Inaktiv Domains auch auf beiden Geräten ein Problem.

Funktion dac_override gewähren

Eine dac_override-Ablehnung bedeutet, dass der anstößige Prozess Sie versuchen, auf eine Datei mit den falschen Unix-Berechtigungen für Nutzer/Gruppen/World zuzugreifen. Die richtige Lösung besteht fast nie darin, die Berechtigung dac_override zu gewähren. Stattdessen die Unix-Berechtigungen für die Datei oder den Prozess ändern. Einige Domains wie init, vold und installd sind wirklich notwendig die Möglichkeit, Unix-Dateiberechtigungen zu überschreiben, um auf die Dateien anderer Prozesse zuzugreifen. Blog von Dan Walsh ansehen finden Sie eine genauere Erklärung.