Google setzt sich dafür ein, die Rassengerechtigkeit für schwarze Gemeinschaften zu fördern. Siehe wie.
Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Vendor Init

Der Init-Prozess verfügt über nahezu uneingeschränkte Berechtigungen und verwendet Eingabeskripts sowohl von der System- als auch von der Herstellerpartition, um das System während des Startvorgangs zu initialisieren. Dieser Zugriff führt zu einer großen Lücke in der Aufteilung von Treble-System und Anbieter, da Anbieterskripte init anweisen können, auf Dateien, Eigenschaften usw. zuzugreifen, die nicht Teil der stabilen System-Anbieter-Anwendungsbinärschnittstelle (ABI) sind.

Vendor init wurde entwickelt, um diese Lücke zu schließen, indem eine separate sicherheitsverbesserte Linux-Domäne (SELinux) vendor_init , um in /vendor gefundene Befehle mit herstellerspezifischen Berechtigungen auszuführen.

Mechanismus

Vendor init gibtelt zu Beginn des Startvorgangs einen Unterprozess von init mit dem SELinux-Kontext u:r:vendor_init:s0 . 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 sind oder Teil des stabilen System-Hersteller-ABI.

Init überprüft jedes geladene Skript, um festzustellen, ob sein Pfad mit /vendor beginnt /vendor und markiert es in diesem Fall mit dem Hinweis, dass seine Befehle im init-Kontext des Anbieters ausgeführt werden müssen. Jedes eingebaute Init ist mit einem Booleschen Wert versehen, der angibt, ob der Befehl im Vendor-Init-Unterprozess ausgeführt werden muss oder nicht:

  • Die meisten Befehle, die auf das Dateisystem zugreifen, sind mit Anmerkungen versehen, um im Vendor Init-Unterprozess ausgeführt zu werden, und unterliegen daher der Vendor Init SEPolicy.
  • Die meisten Befehle, die sich auf den internen Init-Status auswirken (z. B. 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 Behandlung mit Nicht-SELinux-Berechtigungen durchzuführen.

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

Verwenden von Vendor Init

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

Wenn jedoch Befehle in einem bestimmten Herstellerskript gegen die Init-Einschränkungen des Herstellers verstoßen, schlagen die Befehle fehl. Fehlerhafte Befehle haben eine Zeile im Kernel-Protokoll (sichtbar mit dmesg) 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 dreifach neu implementiert werden und nur stabile Schnittstellen durchlaufen. Neverallow-Regeln verhindern das Hinzufügen von Berechtigungen für den Zugriff auf Systemdateien, die nicht Teil des stabilen ABI des Systemherstellers sind.
  • Wenn das SELinux-Label neu ist und noch keine Berechtigungen im System vendor_init.te oder Berechtigungen über die Neverallow-Regeln ausgeschlossen wurden, kann dem neuen Label Berechtigungen im gerätespezifischen vendor_init.te .

Bei Geräten, die vor Android 9 gestartet werden, können die Neverallows-Regeln umgangen werden, indem das data_between_core_and_vendor_violators data_between_core_and_vendor_violators zur vendor_init.te Datei vendor_init.te wird.

Code-Speicherorte

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

Die BuiltinFunctionMap 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 wird in die Verzeichnisse private ( system / sepolicy / private / vendor_init.te ) und public ( system / sepolicy / public / vendor_init.te ) in system / sepolicy aufgeteilt.