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

Dostosowywanie SELinux

Po zintegrowaniu podstawowego poziomu funkcjonalności SELinux i dokładnej analizie wyników, możesz dodać własne ustawienia zasad, aby objąć swoje dostosowania w systemie operacyjnym Android. Te zasady muszą nadal spełniać wymagania programu zgodności z systemem Android i nie mogą usuwać domyślnych ustawień SELinux.

Producenci nie powinni usuwać istniejącej polityki SELinux. W przeciwnym razie ryzykują zerwanie implementacji Androida SELinux i aplikacji, którymi zarządza. Obejmuje to aplikacje innych firm, które prawdopodobnie będą wymagały ulepszenia, aby były zgodne i działały. Aplikacje nie mogą wymagać żadnych modyfikacji, aby mogły dalej działać na urządzeniach obsługujących SELinux.

Przystępując do dostosowywania SELinux pamiętaj, aby:

  • Napisz politykę SELinux dla wszystkich nowych demonów
  • W razie potrzeby używaj wstępnie zdefiniowanych domen
  • Przypisz domenę do dowolnego procesu uruchomionego jako usługa init
  • Zapoznaj się z makrami przed napisaniem zasad
  • Prześlij zmiany w podstawowych zasadach do AOSP

I pamiętaj, aby nie:

  • Utwórz niezgodne zasady
  • Zezwalaj na dostosowywanie zasad użytkownika końcowego
  • Zezwalaj na dostosowywanie zasad MDM
  • Przestraszyć użytkowników naruszeniem zasad
  • Dodaj tylne drzwi

Szczegółowe wymagania można znaleźć w sekcji Funkcje zabezpieczeń jądra w dokumencie Definicja zgodności systemu Android .

SELinux używa metody białej listy, co oznacza, że ​​każdy dostęp musi być wyraźnie dozwolony w polityce, aby mógł zostać przyznany. Ponieważ domyślna polityka SELinux systemu Android obsługuje już projekt Android Open Source, nie musisz w żaden sposób modyfikować ustawień SELinux. Jeśli dostosujesz ustawienia SELinux, bardzo uważaj, aby nie uszkodzić istniejących aplikacji. Rozpocząć:

  1. Użyj najnowszego jądra Androida .
  2. Przyjmij zasadę najmniejszego przywileju .
  3. Zajmij się tylko własnymi dodatkami do Androida. Domyślna zasada działa automatycznie z bazą kodu Android Open Source Project .
  4. Podziel komponenty oprogramowania na moduły, które wykonują pojedyncze zadania.
  5. Utwórz polityki SELinux, które izolują te zadania od niepowiązanych funkcji.
  6. Umieść te polityki w plikach *.te (rozszerzenie plików źródłowych strategii SELinuksa) w katalogu /device/ manufacturer / device-name /sepolicy i użyj zmiennych BOARD_SEPOLICY , aby uwzględnić je w kompilacji.
  7. Na początku uczyń nowe domeny liberalnymi. Odbywa się to za pomocą zezwalającej deklaracji w pliku .te domeny.
  8. Analizuj wyniki i doprecyzuj definicje domen.
  9. Usuń zezwalającą deklarację, gdy w kompilacjach userdebug nie pojawiają się dalsze odmowy.

Po zintegrowaniu zmiany polityki SELinux dodaj krok do przepływu pracy, aby zapewnić zgodność z SELinux w przyszłości. W idealnym procesie tworzenia oprogramowania polityka SELinux zmienia się tylko wtedy, gdy zmienia się model oprogramowania, a nie rzeczywista implementacja.

Gdy zaczniesz dostosowywać SELinux, najpierw sprawdź dodatki do Androida. Jeśli dodano komponent, który wykonuje nową funkcję, przed włączeniem trybu wymuszania upewnij się, że jest on zgodny z zasadami bezpieczeństwa systemu Android, a także z wszelkimi powiązanymi zasadami utworzonymi przez producenta OEM.

Aby uniknąć niepotrzebnych problemów, lepiej być zbyt obszernym i nadmiernie kompatybilnym niż zbyt restrykcyjnym i niekompatybilnym, co skutkuje zepsutymi funkcjami urządzenia. I odwrotnie, jeśli twoje zmiany przyniosą korzyści innym, powinieneś przesłać modyfikacje do domyślnej polityki SELinux jako łatkę . Jeśli poprawka zostanie zastosowana do domyślnej zasady bezpieczeństwa, nie będziesz musiał wprowadzać tej zmiany przy każdej nowej wersji Androida.

Przykładowe oświadczenia dotyczące zasad

SELinux jest oparty na języku komputerowym M4 i dlatego obsługuje wiele makr, aby zaoszczędzić czas.

W poniższym przykładzie wszystkie domeny mają dostęp do odczytu lub zapisu do /dev/null i odczytu z /dev/zero .

# Allow read / write access to /dev/null
allow domain null_device:chr_file { getattr open read ioctl lock append write};

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file { getattr open read ioctl lock };

Tę samą instrukcję można napisać za *_file_perms makr SELinux *_file_perms (skrót):

# Allow read / write access to /dev/null
allow domain null_device:chr_file rw_file_perms;

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file r_file_perms;

Przykładowa polityka

Oto pełna przykładowa polityka dla DHCP, którą przeanalizujemy poniżej:

type dhcp, domain;
permissive dhcp;
type dhcp_exec, exec_type, file_type;
type dhcp_data_file, file_type, data_file_type;

init_daemon_domain(dhcp)
net_domain(dhcp)

allow dhcp self:capability { setgid setuid net_admin net_raw net_bind_service
};
allow dhcp self:packet_socket create_socket_perms;
allow dhcp self:netlink_route_socket { create_socket_perms nlmsg_write };
allow dhcp shell_exec:file rx_file_perms;
allow dhcp system_file:file rx_file_perms;
# For /proc/sys/net/ipv4/conf/*/promote_secondaries
allow dhcp proc_net:file write;
allow dhcp system_prop:property_service set ;
unix_socket_connect(dhcp, property, init)

type_transition dhcp system_data_file:{ dir file } dhcp_data_file;
allow dhcp dhcp_data_file:dir create_dir_perms;
allow dhcp dhcp_data_file:file create_file_perms;

allow dhcp netd:fd use;
allow dhcp netd:fifo_file rw_file_perms;
allow dhcp netd:{ dgram_socket_class_set unix_stream_socket } { read write };
allow dhcp netd:{ netlink_kobject_uevent_socket netlink_route_socket
netlink_nflog_socket } { read write };

Rozważmy przykład:

W pierwszym wierszu deklaracji typu demon DHCP dziedziczy z podstawowej polityki bezpieczeństwa ( domain ). Z poprzednich przykładów instrukcji DHCP może odczytywać i zapisywać do /dev/null .

W drugim wierszu DHCP jest identyfikowana jako domena zezwalająca.

W linii init_daemon_domain(dhcp) polityka stwierdza, że ​​DHCP jest init_daemon_domain(dhcp) z init i może się z nim komunikować.

W net_domain(dhcp) zasada umożliwia net_domain(dhcp) DHCP korzystanie z typowych funkcji net domeny net takich jak odczytywanie i zapisywanie pakietów TCP, komunikacja przez gniazda i wykonywanie żądań DNS.

W linii allow dhcp proc_net:file write; , polityka stwierdza, że ​​DHCP może zapisywać do określonych plików w /proc . Ta linia demonstruje szczegółowe etykietowanie plików w SELinuksie. Używa etykiety proc_net aby ograniczyć dostęp do zapisu tylko do plików w /proc/sys/net .

Ostatni blok przykładu zaczynający się od allow dhcp netd:fd use; przedstawia, w jaki sposób aplikacje mogą współpracować ze sobą. Polityka mówi, że DHCP i netd mogą komunikować się ze sobą za pośrednictwem deskryptorów plików, plików FIFO, gniazd datagramowych i gniazd strumieniowych UNIX. DHCP może tylko odczytywać i zapisywać z gniazd datagramowych i gniazd strumieniowych UNIX i nie może ich tworzyć ani otwierać.

Dostępne sterowanie

Klasa Pozwolenie
plik
ioctl read write create getattr setattr lock relabelfrom relabelto append
unlink link rename execute swapon quotaon mounton
informator
add_name remove_name reparent search rmdir open audit_access execmod
gniazdo elektryczne
ioctl read write create getattr setattr lock relabelfrom relabelto append bind
connect listen accept getopt setopt shutdown recvfrom sendto recv_msg send_msg
name_bind
system plików
mount remount unmount getattr relabelfrom relabelto transition associate
quotamod quotaget
proces
fork transition sigchld sigkill sigstop signull signal ptrace getsched setsched
getsession getpgid setpgid getcap setcap share getattr setexec setfscreate
noatsecure siginh setrlimit rlimitinh dyntransition setcurrent execmem
execstack execheap setkeycreate setsockcreate
bezpieczeństwo
compute_av compute_create compute_member check_context load_policy
compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot
read_policy
zdolność
chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap
linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock
ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin
sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write
audit_control setfcap

WIĘCEJ

I WIĘCEJ

zasady nigdy nie pozwalają

neverallow SELinux neverallow zabraniają zachowania, które nigdy nie powinno mieć miejsca. Dzięki testowaniu zgodności reguły SELinux neverallow pozwalają na egzekwowanie reguł na różnych urządzeniach.

Poniższe wskazówki mają pomóc producentom uniknąć błędów związanych z regułami neverallow podczas dostosowywania. Numery reguł tutaj użyte odpowiadają systemowi Android 5.1 i mogą ulec zmianie wraz z wydaniem.

Reguła 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
Zobacz stronę ptrace dla ptrace . Możliwość sys_ptrace umożliwia ptrace dowolnego procesu, co pozwala na dużą kontrolę nad innymi procesami i powinno należeć tylko do wyznaczonych komponentów systemu, opisanych w regule. Potrzeba tej możliwości często wskazuje na obecność czegoś, co nie jest przeznaczone dla kompilacji dla użytkowników lub funkcji, które nie są potrzebne. Usuń niepotrzebny komponent.

Reguła 76: neverallow { domain -appdomain -dumpstate -shell -system_server -zygote } { file_type -system_file -exec_type }:file execute;
Ta reguła ma na celu zapobieżenie wykonaniu dowolnego kodu w systemie. W szczególności zapewnia, że ​​wykonywany jest tylko kod w /system , co zapewnia gwarancje bezpieczeństwa dzięki mechanizmom takim jak zweryfikowany rozruch. Często najlepszym rozwiązaniem w przypadku napotkania problemu z tą regułą neverallow jest przeniesienie kodu naruszającego prawa na partycję /system .

Dostosowywanie SEPolicy w systemie Android 8.0+

Ta sekcja zawiera wytyczne dotyczące polityki SELinux dostawcy w systemie Android 8.0 i nowszych, w tym szczegółowe informacje na temat rozszerzeń SEPolicy i SEPolicy dla Android Open Source Project (AOSP). Aby uzyskać więcej informacji o tym, w jaki sposób zasady SELinux są zgodne z partycjami i wersjami systemu Android, zobacz Zgodność .

Umieszczenie zasad

W systemie Android 7.0 i wcześniejszych producenci urządzeń mogli dodawać zasady do BOARD_SEPOLICY_DIRS , w tym zasady mające na celu rozszerzenie zasad AOSP na różne typy urządzeń. W systemie Android 8.0 i nowszych dodanie zasady do BOARD_SEPOLICY_DIRS powoduje umieszczenie zasad tylko w obrazie dostawcy.

W systemie Android 8.0 i nowszym zasady istnieją w następujących lokalizacjach w AOSP:

  • system / sepolicy / public . Obejmuje zasady wyeksportowane do użycia w zasadach specyficznych dla dostawcy. Wszystko trafia do infrastruktury zgodności z systemem Android 8.0. Polityka publiczna ma trwać we wszystkich wersjach, więc możesz uwzględnić wszystko /public w swoich niestandardowych zasadach. Z tego powodu rodzaj polityki, którą można umieścić /public jest bardziej ograniczony. Rozważ to wyeksportowany interfejs API zasad platformy: wszystko, co dotyczy interfejsu między /system i /vendor należy tutaj.
  • system / sepolicy / private . Zawiera politykę niezbędną do funkcjonowania obrazu systemu, o której jednak nie powinna wiedzieć polityka obrazu dostawcy.
  • system / sepolicy / vendor . Obejmuje zasady dotyczące komponentów, które trafiają do katalogu /vendor ale istnieją w głównym drzewie platformy (nie w katalogach specyficznych dla urządzenia). Jest to artefakt rozróżnienia systemu kompilacji na urządzenia i komponenty globalne; Koncepcyjnie jest to część zasad dotyczących urządzeń opisanych poniżej.
  • urządzenie / manufacturer / device-name / sepolicy . Obejmuje zasady dotyczące urządzeń. Obejmuje również dostosowania urządzeń do zasad, które w systemie Android 8.0 i nowszym odpowiadają zasadom dotyczącym składników w obrazie dostawcy.

Obsługiwane scenariusze zasad

Na urządzeniach z systemem Android 8.0 lub nowszym obraz dostawcy musi współpracować z obrazem systemu OEM i referencyjnym obrazem systemu AOSP dostarczonym przez Google (i przekazać CTS na tym obrazie referencyjnym). Te wymagania zapewniają wyraźne oddzielenie struktury od kodu dostawcy. Takie urządzenia obsługują następujące scenariusze.

rozszerzenia dostawcy tylko z obrazem

Przykład : dodanie nowej usługi do vndservicemanager z obrazu dostawcy, która obsługuje procesy z obrazu dostawcy.

Podobnie jak w przypadku urządzeń uruchamianych z poprzednimi wersjami Androida, dodaj dostosowanie specyficzne dla device/ manufacturer / device-name /sepolicy w device/ manufacturer / device-name /sepolicy . Nowa polityka regulująca interakcje komponentów dostawcy z (tylko) komponentami innych dostawców powinna obejmować typy obecne tylko w device/ manufacturer / device-name /sepolicy . Polityka napisana tutaj pozwala na działanie kodu dostawcy, nie będzie aktualizowana jako część OTA tylko w ramach i będzie obecna w połączonej polityce na urządzeniu z referencyjnym obrazem systemu AOSP.

obsługa obrazu dostawcy do pracy z AOSP

Przykład : dodanie nowego procesu (zarejestrowanego w hwservicemanager z obrazu dostawcy), który implementuje warstwę HAL zdefiniowaną przez AOSP.

Podobnie jak w przypadku urządzeń uruchamianych z poprzednimi wersjami Androida, dostosuj specyficzne dla device/ manufacturer / device-name /sepolicy . Polityka wyeksportowana jako część system/sepolicy/public/ jest dostępna do użytku i jest wysyłana jako część polityki sprzedawcy. Typy i atrybuty z polityki publicznej mogą być używane w nowych regułach dyktujących interakcje z nowymi bitami specyficznymi dla dostawcy, z zastrzeżeniem neverallow ograniczeń neverallow . Podobnie jak w przypadku tylko dostawcy, nowe zasady tutaj nie będą aktualizowane jako część OTA tylko w ramach i będą obecne w połączonych zasadach na urządzeniu z referencyjnym obrazem systemu AOSP.

rozszerzenia tylko do obrazu systemu

Przykład : Dodanie nowej usługi (zarejestrowanej w servicemanager), do której dostęp mają tylko inne procesy z obrazu systemu.

Dodaj tę politykę do system/sepolicy/private . Możesz dodać dodatkowe procesy lub obiekty, aby włączyć funkcjonalność w obrazie systemu partnera, pod warunkiem, że te nowe bity nie muszą wchodzić w interakcje z nowymi komponentami obrazu dostawcy (w szczególności takie procesy lub obiekty muszą w pełni funkcjonować bez zasad z obrazu dostawcy) . Polityka wyeksportowana przez system/sepolicy/public jest dostępna tutaj, tak samo jak w przypadku rozszerzeń tylko z obrazem dostawcy. Ta zasada jest częścią obrazu systemu i może zostać zaktualizowana w ramach OTA tylko w ramach, ale nie będzie obecna podczas korzystania z referencyjnego obrazu systemu AOSP.

rozszerzenia obrazu dostawcy, które obsługują rozszerzone komponenty AOSP

Przykład: nowa warstwa HAL inna niż AOSP do użytku przez klientów rozszerzonych, którzy również istnieją w obrazie systemu AOSP (na przykład rozszerzony serwer_systemowy).

Zasady interakcji między systemem a dostawcą muszą być zawarte w katalogu device/ manufacturer / device-name /sepolicy dostarczonym na partycji dostawcy. Jest to podobne do powyższego scenariusza dodawania obsługi obrazu dostawcy do pracy z referencyjnym obrazem AOSP, z wyjątkiem tego, że zmodyfikowane komponenty AOSP mogą również wymagać dodatkowej polityki, aby poprawnie działać z resztą partycji systemowej (co jest w porządku, o ile nadal mieć publiczne etykiety typu AOSP).

Zasady interakcji publicznych komponentów AOSP z rozszerzeniami zawierającymi tylko obraz systemu powinny znajdować się w system/sepolicy/private .

rozszerzenia obrazu systemu, które mają dostęp tylko do interfejsów AOSP

Przykład: nowy proces systemowy inny niż AOSP musi uzyskać dostęp do warstwy HAL, na której opiera się AOSP.

Jest to podobne do przykładu rozszerzenia zawierającego tylko obraz systemu , z wyjątkiem tego, że nowe składniki systemu mogą wchodzić w interakcje w ramach interfejsu system/vendor . Polityka dla nowego komponentu systemu musi zostać umieszczona w system/sepolicy/private , co jest dopuszczalne pod warunkiem, że odbywa się za pośrednictwem interfejsu już ustanowionego przez AOSP w system/sepolicy/public (tj. Są tam typy i atrybuty wymagane dla funkcjonalności). Chociaż zasady mogłyby zostać uwzględnione w zasadach specyficznych dla urządzenia, nie byłyby one w stanie używać innych typów system/sepolicy/private ani zmieniać (w jakikolwiek sposób wpływających na zasady) w wyniku aktualizacji system/sepolicy/private platformy. Polityka może zostać zmieniona w OTA tylko dla frameworka, ale nie będzie obecna podczas korzystania z obrazu systemu AOSP (który również nie będzie miał nowego składnika systemu).

rozszerzenia obrazu dostawcy, które obsługują nowe składniki systemu

Przykład: Dodanie nowej warstwy HAL innej niż AOSP do użycia przez proces klienta bez analogu AOSP (a zatem wymaga własnej domeny).

Podobnie jak w przykładzie rozszerzeń AOSP , zasady dotyczące interakcji między systemem a dostawcą muszą device/ manufacturer / device-name /sepolicy katalogu device/ manufacturer / device-name /sepolicy dostarczonym na partycji dostawcy (aby zapewnić, że polityka systemu nie ma wiedzy o szczegółach dotyczących dostawcy). Możesz dodać nowe typy publiczne, które rozszerzają politykę w system/sepolicy/public ; należy to zrobić tylko w uzupełnieniu do istniejącej polityki AOSP, tj. nie usuwać polityki publicznej AOSP. Nowe typy publiczne mogą być następnie wykorzystane do polityki w system/sepolicy/private i device/ manufacturer / device-name /sepolicy .

Należy pamiętać, że każdy dodatek do system/sepolicy/public zwiększa złożoność, udostępniając nową gwarancję zgodności, którą należy śledzić w pliku mapowania i która podlega innym ograniczeniom. Tylko nowe typy i odpowiadające im reguły zezwalania mogą być dodawane w system/sepolicy/public ; atrybuty i inne instrukcje strategiczne nie są obsługiwane. Ponadto nowych typów publicznych nie można używać do bezpośredniego oznaczania obiektów w zasadach /vendor .

Nieobsługiwane scenariusze zasad

Urządzenia z systemem Android 8.0 lub nowszym nie obsługują następującego scenariusza zasad i przykładów.

Dodatkowe rozszerzenia do obrazu systemu, które wymagają pozwolenia na nowe komponenty obrazu dostawcy po OTA tylko dla struktury

Przykład: nowy proces systemowy inny niż AOSP, wymagający własnej domeny, zostanie dodany w następnej wersji Androida i potrzebuje dostępu do nowej warstwy HAL innej niż AOSP.

Podobnie jak w przypadku interakcji nowego (innego niż AOSP) systemu i komponentów dostawcy , z wyjątkiem tego, że nowy typ systemu jest wprowadzany w OTA tylko z ramą. Chociaż nowy typ można dodać do zasad w system/sepolicy/public , istniejące zasady dostawcy nie mają wiedzy na temat nowego typu, ponieważ śledzą tylko zasady publiczne systemu Android 8.0. AOSP radzi sobie z tym, ujawniając zasoby dostarczone przez dostawcę za pośrednictwem atrybutu (np. hal_foo ), ale ponieważ rozszerzenia partnerów atrybutów nie są obsługiwane w system/sepolicy/public , ta metoda jest niedostępna dla zasad dostawcy. Dostęp musi być zapewniony przez wcześniej istniejący typ publiczny.

Przykład: Zmiana w procesie systemowym (AOSP lub innym niż AOSP) musi zmienić sposób, w jaki współdziała z nowym składnikiem dostawcy spoza AOSP.

Zasady dotyczące obrazu systemu muszą być napisane bez wiedzy o dostosowaniach określonych przez dostawców. Polityka dotycząca określonych interfejsów w AOSP jest zatem ujawniana za pośrednictwem atrybutów w systemie / sepolicy / public, dzięki czemu polityka dostawcy może zaakceptować przyszłą politykę systemową, która używa tych atrybutów. Jednak rozszerzenia atrybutów w system/sepolicy/public nie są obsługiwane , więc wszystkie zasady określające sposób interakcji komponentów systemu z nowymi komponentami dostawcy (i które nie są obsługiwane przez atrybuty już obecne w system/sepolicy/public ) muszą znajdować się w device/ manufacturer / device-name /sepolicy . Oznacza to, że typy systemów nie mogą zmieniać dozwolonego dostępu do typów dostawców w ramach OTA tylko w ramach platformy.