Inicjacja dostawcy

Proces inicjowania ma niemal nieograniczone uprawnienia i wykorzystuje skrypty wejściowe z zarówno partycji systemu, jak i dostawcy, aby zainicjować system podczas rozruchu. proces tworzenia konta. W takiej sytuacji powstaje olbrzymia dziura w systemie Treble i podział dostawców, skrypty dostawcy mogą inicjować dostęp do plików, właściwości itd., które nie umożliwiają wchodzą w skład stabilnego interfejsu binarnego aplikacji dostawcy systemu – ABI.

Inicjowanie dostawcy ma na celu zamknięcie tego otworu przez użycie osobnego tagu do uruchomienia domeny vendor_init z ulepszonymi zabezpieczeniami (SELinux) Znalezione polecenia w /vendor z uprawnieniami konkretnego dostawcy.

Mechanizm

Dostawca inicjuje podproces inicjowania na samym początku Kontekst SELinux u:r:vendor_init:s0. Ten kontekst SELinux zawiera znacznie mniej uprawnień niż domyślny kontekst początkowy, a jego dostęp jest ograniczone do plików, właściwości itp., które dotyczą konkretnego dostawcy lub są częścią na stabilnym interfejsie ABI dostawcy systemu.

Init sprawdza każdy wczytywany skrypt, by zobaczyć, czy jego ścieżka zaczyna się od /vendor, a jeśli tak, oznacza go tagiem, że jego polecenia musi działać w kontekście dostawcy. Każda wbudowana inicjacja jest opatrzona adnotacją wartość logiczna określająca, czy to polecenie musi być wykonywane w inicjowaniu dostawcy proces podrzędny:

• Większość poleceń uzyskujących dostęp do systemu plików ma adnotacje do uruchamiania u dostawcy i w związku z tym podlegają zasadom SEPolicy zainicjowanym przez dostawcę.
• Większość poleceń, które mają wpływ na stan uruchomienia wewnętrznego (np. uruchamianie i zatrzymywanie usług) są uruchamiane w ramach normalnego procesu inicjowania. Te polecenia są tworzone wiedzą, że skrypt dostawcy wywołał go w celu wykonania własnych instrukcji obsługi uprawnień.

Główna pętla przetwarzania inicjowania zawiera sprawdzenie, czy polecenie jest oznaczone adnotacjami które można uruchomić w podprocesie dostawcy i pochodzi ze skryptu dostawcy, jest wysyłane w ramach komunikacji międzyprocesowej (IPC) do metody inicjowanej przez dostawcę. które uruchamia polecenie i wysyła wynik z powrotem do inicjowania.

Korzystanie z metody Vendor Init

Inicjowanie dostawcy jest domyślnie włączone, a jego ograniczenia mają zastosowanie do wszystkich skryptów inicjujących w partycji /vendor. Inicjatywy dostawcy powinny być przejrzyste dostawcom, których skrypty nie mają już dostępu do plików tylko systemowych, właściwości itp.

Jeśli jednak polecenia w skrypcie danego dostawcy naruszają inicjalizację dostawcy , polecenia nie zadziałają. Polecenia nieudane mają wiersz w jądrze log (widoczny z poleceniem dmesg) z pliku init, co oznacza niepowodzenie. Audyt SELinux towarzyszy każdym nieudanym poleceniom, których nie udało się ze względu na zasadę SELinux. Przykład m.in. audytu SELinux:

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

Jeśli polecenie nie zadziała, masz 2 możliwości:

• Jeśli polecenie kończy się niepowodzeniem z powodu zamierzonego ograniczenia (np. uzyskuje dostęp do pliku systemowego lub właściwości), musi to być został ponownie zaimplementowany w sposób dostosowany do Treble i używał tylko stabilnych interfejsów. Reguły typu „Nigdy nie zezwalaj” uniemożliwiają dodawanie uprawnień dostępu do plików systemowych, które nie są jest częścią stabilnego interfejsu ABI dostawcy systemu.
• Jeśli etykieta SELinux jest nowa i nie ma jeszcze uprawnień w system vendor_init.te ani wykluczone uprawnienia za pomocą metody Nigdy nie zezwalaj do reguł, nowa etykieta może mieć uprawnienia tylko vendor_init.te

Na urządzeniach wprowadzonych na rynek przed wersją Androida 9 reguły „Nigdy nie zezwalaj” mogą zostać pominięte przez dodając atrybut type data_between_core_and_vendor_violators do plik vendor_init.te powiązany z konkretnym urządzeniem.

Lokalizacje kodu

Większa część logiki IPC inicjowanego przez dostawcę znajduje się w pliku system/core/init/subcontext.cpp.

Tabela poleceń znajduje się w klasie BuiltinFunctionMap w pliku system/core/init/builtins.cpp i zawiera adnotacje wskazujące, czy to polecenie musi być uruchamiane u dostawcy zainicjuj jego proces.

Zasada SEPolicy dotycząca inicjowania dostawcy jest podzielona na obszar prywatny (system/sepolicy/private/vendor_init.te). i publiczny (system/sepolicy/public/vendor_init.te) w katalogu system/sepolicy.