Anbieterinit

Der Init-Prozess verfügt über nahezu unbegrenzte Berechtigungen und verwendet Eingabeskripts aus sowohl die System- als auch die Anbieterpartitionen, um das System während des Starts zu initialisieren . Dieser Zugang führt zu einem riesigen Loch im Treble-System/Anbieter-Split, Anbieterskripts können init anweisen, auf Dateien, Eigenschaften usw. zuzugreifen, die keine sind Teil der stabilen System-Vendor-Anwendungs-Binärschnittstelle (ABI).

Die anbieterseitige Initialisierung wurde entwickelt, um diese Öffnung zu schließen, indem eine separate Ausführung der sicherheitsoptimierten Linux-Domain (SELinux) vendor_init Befehle in /vendor mit anbieterspezifischen Berechtigungen.

Mechanismus

Der anbieterseitige Init-Prozess verzweigt zu Beginn des Boot-Prozesses einen Unterprozess der Init-Methode mit dem SELinux-Kontext u:r:vendor_init:s0. Dieser SELinux-Kontext hat erheblich weniger Berechtigungen als der Standard-Init-Kontext und der Zugriff die auf Dateien, Eigenschaften usw. beschränkt sind, die entweder anbieterspezifisch sind oder Teil eines des stabilen Systemanbieters ABI.

Init prüft jedes geladene Script, um festzustellen, ob der Pfad mit folgendem Wert beginnt: /vendor. Wenn ja, wird er mit einem Hinweis versehen, dass seine Befehle muss im Anbieter-init-Kontext ausgeführt werden. Jedes integrierte Initialisierungssystem ist mit einem Boolescher Wert, der angibt, ob der Befehl in der Anbieterinitialisierung ausgeführt werden muss Teilprozess:

  • Die meisten Befehle, die auf das Dateisystem zugreifen, sind so annotiert, dass sie im Anbieter ausgeführt werden. und unterliegen daher der init-SEPolicy des Anbieters.
  • Die meisten Befehle, die sich auf den internen Initialisierungsstatus auswirken (z.B. Starten und Stoppen) Services) werden innerhalb des normalen Init-Prozesses ausgeführt. Diese Befehle werden wissen, dass sie von einem Anbieterskript aufgerufen werden, damit sie ihr eigenes Nicht-SELinux erstellen Umgang mit Berechtigungen.

Die Hauptverarbeitungsschleife von „init“ enthält eine Prüfung, ob ein Befehl annotiert ist im Unterprozess des Anbieters ausgeführt werden soll und stammt aus einem Anbieterskript, Der Befehl wird per IPC (Inter-Process Communication) an die Anbieterinit-Instanz gesendet. , der den Befehl ausführt und das Ergebnis an die Initialisierung zurücksendet.

Vendor Init verwenden

Die anbieterseitige Initialisierung ist standardmäßig aktiviert und die zugehörigen Einschränkungen gelten für alle init-Skripts in der Partition /vendor vorhanden ist. Anbieterinit sollte transparent sein für Anbieter, deren Skripts bereits auf reine Systemdateien zugreifen, Properties usw.

Wenn Befehle in einem bestimmten Anbieterskript jedoch gegen die Anbieterinit verstoßen, schlagen die Befehle fehl. Bei fehlerhaften Befehlen wird im Kernel eine Zeile angezeigt log (sichtbar mit dmesg) von init, das einen Fehler anzeigt. Ein SELinux-Audit begleitet jeden fehlerhaften Befehl, der aufgrund der SELinux-Richtlinie fehlgeschlagen ist. Beispiel eines Fehlers einschließlich SELinux-Audit: 

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 das Befehl auf eine Systemdatei oder ein Attribut zugreift), muss der Befehl auf Treble-freundliche Weise neu implementiert und dabei nur stabile Schnittstellen verwendet. Durch „Niezulassen“-Regeln wird das Hinzufügen von Berechtigungen für den Zugriff auf Systemdateien verhindert, die nicht des stabilen Systemanbieters ABI.
  • Wenn das SELinux-Label neu ist und noch keine Berechtigungen im System-vendor_init.te oder ausgeschlossene Berechtigungen über die Methode "Neverallow" können dem neuen Label Berechtigungen im gerätespezifischen vendor_init.te

Bei Geräten, die vor Android 9 auf den Markt gebracht wurden, können die "Neverallows"-Regeln durch durch Hinzufügen des Typattributs data_between_core_and_vendor_violators zu die gerätespezifische vendor_init.te-Datei

Speicherorte des Codes

Der Großteil der Logik für die init-IPC des Anbieters befindet sich in system/core/init/subcontext.cpp.

Die Tabelle der Befehle befindet sich in der Klasse BuiltinFunctionMap in system/core/init/builtins.cpp. und enthält Annotationen, die angeben, ob der Befehl beim Anbieter ausgeführt werden muss. init.

Die SEPolicy für die Anbieterinit ist auf die private Ebene aufgeteilt (system/sepolicy/private/vendor_init.te). und öffentlich (system/sepolicy/public/vendor_init.te) in system/sepolicy.