Anbieter-Init

Der Init-Prozess verfügt über nahezu uneingeschränkte Berechtigungen und verwendet Eingabeskripte sowohl von der System- als auch von der Herstellerpartition, um das System während des Startvorgangs zu initialisieren. Dieser Zugriff verursacht eine große Lücke in der Treble-System/Anbieter-Trennung, da Anbieterskripte init möglicherweise anweisen, auf Dateien, Eigenschaften usw. zuzugreifen, die nicht Teil der stabilen System-Anbieter-Anwendungsbinärschnittstelle (ABI) sind.

Vendor Init soll diese Lücke schließen, indem es eine separate, sicherheitsverstärkte Linux-Domäne (SELinux) vendor_init verwendet, um Befehle in /vendor mit herstellerspezifischen Berechtigungen auszuführen.

Mechanismus

Vendor init forkt einen Unterprozess von init zu Beginn des Startvorgangs mit dem SELinux-Kontext u:r:vendor_init:s0 auf. Dieser SELinux-Kontext verfügt über erheblich weniger Berechtigungen als der Standard-Init-Kontext und sein Zugriff ist auf Dateien, Eigenschaften usw. beschränkt, die entweder herstellerspezifisch oder Teil der stabilen System-Anbieter-ABI sind.

Init überprüft jedes geladene Skript, um festzustellen, ob sein Pfad mit /vendor beginnt. Ist dies der Fall, markiert es es mit dem Hinweis, dass seine Befehle im Vendor-Init-Kontext ausgeführt werden müssen. Jede integrierte Init-Instanz ist mit einem booleschen Wert versehen, der angibt, ob der Befehl im Init-Unterprozess des Anbieters ausgeführt werden muss oder nicht:

  • Die meisten Befehle, die auf das Dateisystem zugreifen, sind für die Ausführung im Vendor-Init-Unterprozess annotiert und unterliegen daher der Vendor-Init-SEPolicy.
  • Die meisten Befehle, die sich auf den internen Init-Status auswirken (z. B. das Starten und Stoppen von Diensten), werden im normalen Init-Prozess ausgeführt. Diese Befehle werden darauf aufmerksam gemacht, dass ein Herstellerskript sie aufruft, um ihre eigene Nicht-SELinux-Berechtigungsbehandlung durchzuführen.

Die Hauptverarbeitungsschleife von init enthält eine Prüfung, bei der ein Befehl, der für die Ausführung im Anbieter-Unterprozess mit Anmerkungen versehen ist und aus einem Anbieter-Skript stammt, über Interprozesskommunikation (IPC) an den Anbieter-Init-Unterprozess gesendet wird, der den Befehl ausführt und sendet das Ergebnis zurück an init.

Vendor Init verwenden

Vendor Init ist standardmäßig aktiviert und seine Einschränkungen gelten für alle Init-Skripte, die in der /vendor Partition vorhanden sind. Die Anbieterinitialisierung sollte für Anbieter transparent sein, deren Skripte bereits nicht nur auf Systemdateien, Eigenschaften usw. zugreifen.

Wenn jedoch Befehle in einem bestimmten Anbieterskript gegen die Init-Einschränkungen des Anbieters verstoßen, schlagen die Befehle fehl. Bei fehlgeschlagenen Befehlen gibt es im Kernel-Protokoll (sichtbar mit dmesg) eine Zeile von init, die auf einen Fehler hinweist. Ein SELinux-Audit begleitet jeden fehlgeschlagenen Befehl, der aufgrund der SELinux-Richtlinie fehlgeschlagen ist. Beispiel für einen Fehler einschließlich eines SELinux-Audits:

type=1400 audit(1511821362.996:9): avc: denied { search } for pid=540 comm="init" name="nfc" dev="sda45" ino=1310721 scontext=u:r:vendor_init:s0 tcontext=u:object_r:nfc_data_file:s0 tclass=dir permissive=0
init: Command 'write /data/nfc/bad_file_access 1234' action=boot (/vendor/etc/init/hw/init.walleye.rc:422) took 2ms and failed: Unable to write to file '/data/nfc/bad_file_access': open() failed: Permission denied

Wenn ein Befehl fehlschlägt, gibt es zwei Möglichkeiten:

  • Wenn der Befehl aufgrund einer beabsichtigten Einschränkung fehlschlägt (z. B. wenn der Befehl auf eine Systemdatei oder -eigenschaft zugreift), muss der Befehl auf Treble-freundliche Weise neu implementiert werden und darf nur über stabile Schnittstellen erfolgen. Neverallow-Regeln verhindern das Hinzufügen von Berechtigungen für den Zugriff auf Systemdateien, die nicht Teil der stabilen ABI des Systemanbieters sind.
  • Wenn das SELinux-Label neu ist und nicht bereits Berechtigungen im System vendor_init.te gewährt oder über die „Neverallow“-Regeln ausgeschlossene Berechtigungen erhalten wurden, können dem neuen Label Berechtigungen im gerätespezifischen „ vendor_init.te gewährt werden.

Bei Geräten, die vor Android 9 gestartet werden, können die Neverallows-Regeln umgangen werden, indem das Typattribut „ data_between_core_and_vendor_violators “ zur gerätespezifischen Datei vendor_init.te hinzugefügt wird.

Code-Standorte

Der Großteil der Logik für den Hersteller-Init-IPC befindet sich in system/core/init/subcontext.cpp .

Die Befehlstabelle befindet sich in der BuiltinFunctionMap Klasse in system/core/init/builtins.cpp und enthält Anmerkungen, die angeben, ob der Befehl im Vendor-Init-Unterprozess ausgeführt werden muss.

Die SEPolicy für Vendor Init ist auf die privaten ( system/sepolicy/private/vendor_init.te ) und öffentlichen ( system/sepolicy/public/vendor_init.te ) Verzeichnisse in system/sepolicy aufgeteilt.