Google jest zaangażowany w promowanie równości rasowej dla społeczności czarnych. Zobacz jak.
Ta strona została przetłumaczona przez Cloud Translation API.
Switch to English

Vendor Init

Proces init ma prawie nieograniczone uprawnienia i używa skryptów wejściowych zarówno z partycji systemowej, jak i partycji dostawcy, aby zainicjować system podczas procesu rozruchu. Ten dostęp powoduje ogromną dziurę w podziale systemu Treble / dostawcy, ponieważ skrypty dostawcy mogą instruować init, aby uzyskać dostęp do plików, właściwości itp., Które nie stanowią części stabilnego interfejsu binarnego aplikacji dostawcy systemu (ABI).

Vendor init został zaprojektowany, aby zamknąć tę lukę, używając oddzielnej domeny vendor_init z ulepszonymi zabezpieczeniami (SELinux) do uruchamiania poleceń znajdujących się w /vendor z uprawnieniami specyficznymi dla dostawcy.

Mechanizm

u:r:vendor_init:s0 podproces inicjalizacji na początku procesu uruchamiania z kontekstem SELinux u:r:vendor_init:s0 . Ten kontekst SELinuksa ma znacznie mniej uprawnień niż domyślny kontekst inicjalizacji, a jego dostęp jest ograniczony do plików, właściwości itp., Które są albo specyficzne dla dostawcy, albo są częścią stabilnego ABI dostawcy systemu.

Init sprawdza każdy ładowany skrypt, aby zobaczyć, czy jego ścieżka zaczyna się od /vendor a jeśli tak, oznacza go ze wskazaniem, że jego polecenia muszą być uruchamiane w kontekście init dostawcy. Każde polecenie wbudowane init jest opatrzone adnotacją wartością logiczną, która określa, czy polecenie musi zostać uruchomione w podprocesie inicjującym dostawcy:

  • Większość poleceń, które uzyskują dostęp do systemu plików, jest oznaczonych adnotacjami do uruchamiania w podprocesie inicjalizacji dostawcy, a zatem podlega inicjalizacji SEPolicy przez producenta.
  • Większość poleceń, które mają wpływ na wewnętrzny stan inicjalizacji (np. Uruchamianie i zatrzymywanie usług), jest uruchamianych w ramach normalnego procesu inicjowania. Te polecenia są uświadamiane, że skrypt dostawcy wywołuje je w celu wykonania własnej obsługi uprawnień innych niż SELinux.

Główna pętla przetwarzania init zawiera sprawdzenie, czy jeśli polecenie jest opatrzone adnotacją do uruchomienia w podprocesie dostawcy i pochodzi ze skryptu dostawcy, to polecenie jest wysyłane za pośrednictwem komunikacji międzyprocesowej (IPC) do podprocesu inicjowania dostawcy, który uruchamia polecenie i wysyła wynik z powrotem do init.

Korzystanie z inicjalizacji dostawcy

Init dostawcy jest domyślnie włączony, a jego ograniczenia dotyczą wszystkich skryptów inicjalizacyjnych obecnych na partycji /vendor . Init dostawcy powinien być przejrzysty dla dostawców, których skrypty już nie uzyskują dostępu tylko do plików systemowych, właściwości itp.

Jeśli jednak polecenia w danym skrypcie dostawcy naruszają ograniczenia init dostawcy, polecenia zakończą się niepowodzeniem. W przypadku błędnych poleceń w dzienniku jądra (widocznym z dmesg) znajduje się wiersz wskazujący błąd. Audyt SELinuksa towarzyszy każdemu błędnemu poleceniu, które zawiodło z powodu polityki SELinuksa. Przykład awarii obejmującej audyt 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 powiedzie się, istnieją dwie opcje:

  • Jeśli polecenie kończy się niepowodzeniem z powodu zamierzonego ograniczenia (na przykład jeśli polecenie uzyskuje dostęp do pliku systemowego lub właściwości), polecenie musi zostać ponownie zaimplementowane w sposób przyjazny dla treble, przechodząc tylko przez stabilne interfejsy. Reguły Neverallow uniemożliwiają dodawanie uprawnień dostępu do plików systemowych, które nie są częścią stabilnego ABI dostawcy systemu.
  • Jeśli etykieta SELinux jest nowa i nie ma już nadanych uprawnień w systemie vendor_init.te ani wykluczonych uprawnień za pośrednictwem reguł Neverallow, nowej etykiecie można nadać uprawnienia w vendor_init.te specyficznym dla vendor_init.te .

W przypadku urządzeń uruchamianych przed Androidem 9 reguły Neverallows można ominąć, dodając data_between_core_and_vendor_violators type data_between_core_and_vendor_violators do pliku vendor_init.te konkretnego vendor_init.te .

Lokalizacje kodu

Większość logiki inicjującej IPC dostawcy znajduje się w system / core / init / subcontext.cpp .

Tabela poleceń znajduje się w klasie BuiltinFunctionMap w system / core / init / builtins.cpp i zawiera adnotacje wskazujące, czy polecenie musi zostać uruchomione w podprocesie inicjalizacji dostawcy.

Polityka SEPolicy dla init dostawcy jest podzielona na katalogi prywatne ( system / sepolicy / private / vendor_init.te ) i publiczne ( system / sepolicy / public / vendor_init.te ) w system / sepolicy.