Dostosowywanie SELinux

Po zintegrowaniu podstawowego poziomu funkcji SELinux dokładnie przeanalizował wyniki, możesz dodać własne ustawienia zasad, aby uwzględnić dostosowania do systemu operacyjnego Android. Zasady te nie mogą zgodne z Programem zgodności z Androidem. wymagań i nie może usuwać domyślnych ustawień SELinux.

Producenci nie powinni usuwać istniejących zasad SELinux. W przeciwnym razie może uszkodzić implementację Androida SELinux i jego aplikacje reguluje. Obejmuje to aplikacje innych firm, które prawdopodobnie będą musiały być pod kątem zgodności i działania. Aplikacje nie mogą wymagać: na urządzeniach z włączonym SELinux.

Podczas dostosowywania SELinux pamiętaj o tych kwestiach:

• Zapisz zasady SELinux dla wszystkich nowych demonów
• W razie potrzeby używaj wstępnie zdefiniowanych domen
• Przypisz domenę do dowolnego procesu utworzonego jako usługa init
• Zapoznaj się z makrami, zanim utworzysz zasady
• Prześlij zmiany do podstawowych zasad do AOSP

Pamiętaj też, aby:

• Utwórz niezgodną zasadę
• Zezwalaj na dostosowywanie zasad dotyczących użytkowników
• Zezwalaj na dostosowywanie zasad MDM
• Przestraszanie użytkowników naruszeniami zasad
• Dodaj tajne wejście

Zobacz sekcję Funkcje zabezpieczeń jądra w Android Dokument definicji zgodności.

SELinux stosuje białą listę, co oznacza, że każdy dostęp musi być wyraźnie określony. które są dozwolone w zasadach. Domyślny system SELinux Androida zasada obsługuje już projekt Android Open Source, nie musisz więc tego robić aby modyfikować ustawienia SELinux. Jeśli dostosujesz ustawienia SELinux, staraj się nie zepsuć istniejących aplikacji. Aby rozpocząć:

1. Użyj najnowszy Android jądro.
2. Zastosuj zasada przy jak najmniejszych uprawnieniach.
3. Odpowiadaj tylko na własne zmiany w Androidzie. Domyślna zasada działa z: program Android Open Source Projektu automatycznie.
4. Podziel komponenty oprogramowania na moduły, które wykonują zadania.
5. Utwórz zasady SELinux, które odizolują te zadania od niezwiązanych z nimi zadań funkcji.
6. Umieść te zasady w plikach *.te (rozszerzenie dla SELinux) plików źródłowych zasad) w sekcji /device/manufacturer/device-name/sepolicy i użyj zmiennych BOARD_SEPOLICY, aby je uwzględnić i przygotować odpowiedni projekt.
7. Początkowo ustaw nowe domeny jako mniej rygorystyczne. Jest to możliwe dzięki zastosowaniu trybu mniej rygorystycznego w pliku .te domeny.
8. Przeanalizuj wyniki i doprecyzuj definicje domen.
9. Usuń deklarację mniej rygorystyczną, gdy w debugowaniu użytkownika nie pojawiają się kolejne odmowy do tworzenia kampanii.

Po zintegrowaniu zmiany zasad SELinux dodaj krok do w procesie programowania, aby zapewnić zgodność z wersją SELinux. W idealnej sytuacji proces tworzenia oprogramowania, zasady SELinux zmieniają się tylko wtedy, gdy a nie rzeczywistej implementacji.

Gdy zaczniesz dostosowywać SELinux, najpierw sprawdź, jakie elementy zostały dodane do Androida. Jeśli został dodany komponent, który przeprowadza nową funkcję, upewnij się, że komponent są zgodne z zasadami bezpieczeństwa Androida oraz z wszelkimi powiązanymi zasadami OEM, zanim włączysz tryb egzekwowania.

Aby uniknąć niepotrzebnych problemów, lepiej jest przedstawić nadmierne zasięg i zbyt duża niż zbyt restrykcyjna i niezgodna, co powoduje funkcji urządzenia. Jeśli Twoje zmiany przyniosą korzyści innym, prześlij modyfikacje domyślnej zasady SELinux jako patch. Jeśli poprawka jest dla domyślnej zasady zabezpieczeń, nie trzeba będzie wprowadzać tej zmiany każdej nowej wersji Androida.

Przykładowe oświadczenia dotyczące zasad

SELinux opiera się na M4 i obsługuje różne makra, aby zaoszczędzić czas.

W poniższym przykładzie wszystkie domeny mają uprawnienia do odczytu z lub zapisywać w aplikacji /dev/null i odczytywać od: /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 zapisać w 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 zasada

Oto przykładowa zasada dla DHCP, którą omawiamy 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 };

Przeanalizujmy przykład:

W pierwszym wierszu deklaracja typu, którą demon DHCP dziedziczy z parametru podstawowa zasada zabezpieczeń (domain). Z poprzedniego wyciągu DHCP może odczytywać dane z /dev/null i zapisywać w nim.

W drugim wierszu DHCP jest identyfikowany jako domena mniej rygorystyczna.

W wierszu init_daemon_domain(dhcp) stan zasady to DHCP pochodzi z init i może się z nim komunikować.

W wierszu net_domain(dhcp) zasada umożliwia DHCP używanie typowe funkcje sieciowe z domeny net, takie jak odczytywanie oraz zapisywanie pakietów TCP, komunikowanie się przez gniazda i wykonywanie DNS. żądań.

W wierszu allow dhcp proc_net:file write; znajduje się informacja, że zasada DHCP może zapisywać w określonych plikach w obszarze /proc. Ten wiersz pokazuje, Szczegółowe etykiety plików w SELinux. Używa etykiety proc_net aby ograniczyć uprawnienia do zapisu tylko do plików w domenie /proc/sys/net.

Ostatni blok przykładu rozpoczynający się od allow dhcp netd:fd use; przedstawia, jak aplikacje mogą być dostępne: wchodzić ze sobą w interakcję. Zgodnie z zasadami usługi DHCP i netd mogą komunikować się z oraz za pomocą deskryptorów plików, plików FIFO, gniazd datagramów i strumienia UNIX. i gniazdek. DHCP może tylko odczytywać dane z gniazd datagramów oraz system UNIX i z nich zapisywać i nie należy ich tworzyć ani otwierać.

Dostępne ustawienia

ioctl read write create getattr setattr lock relabelfrom relabelto append
unlink link rename execute swapon quotaon mounton

add_name remove_name reparent search rmdir open audit_access execmod

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

mount remount unmount getattr relabelfrom relabelto transition associate
quotamod quotaget

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

compute_av compute_create compute_member check_context load_policy
compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot
read_policy

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

reguły nigdy nie zezwalaj

Reguły SELinux neverallow uniemożliwiają działanie, które nigdy nie powinno mieć miejsca. Dzięki testom zgodności Reguły SELinux neverallow są teraz egzekwowane na wszystkich urządzeniach.

Te wytyczne mają pomóc producentom uniknąć błędów związane z neverallow regułami podczas dostosowywania. Numery reguł są zgodne z Androidem 5.1 i mogą się zmieniać w zależności od wersji.

Reguła 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
Zobacz stronę podręcznika dla języka ptrace. sys_ptrace umożliwia ptrace dowolny proces, co znacznie ułatwia kontroli nad innymi procesami i powinny należeć tylko do wyznaczonego systemu opisane w regule. Potrzeba takiej możliwości często wskazuje, obecności elementów nieprzeznaczonych do tworzenia dla użytkowników lub funkcję, która nie jest potrzebna. Usuń zbędny 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 zapobieganie wykonywaniu w systemie dowolnego kodu. Konkretnie oznacza to, że wykonywany jest tylko kod na stronie /system, który daje gwarancję bezpieczeństwa dzięki mechanizmom takim jak weryfikacja podczas uruchamiania. Często najlepszym rozwiązaniem w przypadku napotkania problemu Reguła neverallow polega na przeniesieniu niewłaściwego kodu do sekcji /system partycja.

Dostosowywanie SEPolicy w Androidzie 8.0 i nowszych

Ta sekcja zawiera wskazówki dotyczące zasad SELinux dostawcy w Androidzie 8.0 i m.in. szczegóły dotyczące Android Open Source Project (AOSP) SEPolicy SEPolicy. Więcej informacji o zachowaniu zasad SELinux zgodne między partycjami i wersjami Androida, zobacz Zgodność.

Umiejscowienie zasad

W Androidzie 7.0 i starszych producenci urządzeń mogą dodawać zasady BOARD_SEPOLICY_DIRS, w tym zasady mające na celu rozszerzenie zasad AOSP na różnych rodzajach urządzeń. W Androidzie 8.0 i nowszych dodanie zasady do BOARD_SEPOLICY_DIRS umieszcza zasadę tylko w usłudze dostawcy .

W Androidzie 8.0 i nowszych zasada znajduje się w AOSP w tych miejscach:

• system/sepolicy/public. Zawiera zasady wyeksportowane do użytku w zasadach dla danego dostawcy. Wszystko dzieje się na Androidzie 8.0 infrastrukturze zgodności. Polityka publiczna musi być niezmienna we wszystkich wersjach, dzięki czemu możesz uwzględniać /public w niestandardowych zasadach. Z tego powodu w zasadzie /public można umieścić ograniczony. Weź pod uwagę eksport zasad API platformy: wszystko, co zawiera umowy między /system a Miejsce na dane /vendor.
• system/sepolicy/private. Obejmuje zasady niezbędne dla obrazu systemu. Obowiązujące zasady dotyczące obrazów systemu nie mają żadnej wiedzy.
• system/sepolicy/vendor. Obejmuje zasady dotyczące komponentów, które: przejdź w /vendor, ale istnieją w podstawowym drzewie platformy (nie katalogów na określone urządzenia). To jest artefakt systemu kompilacji rozróżnienie między urządzeniami a elementami globalnymi; koncepcyjnie jest to stanowi część zasad dotyczących urządzeń opisanych poniżej.
• device/manufacturer/device-name/sepolicy. Obejmuje zasady dla poszczególnych urządzeń. Obejmuje również dostosowanie urządzeń do , która w Androidzie 8.0 i nowszych odpowiada zasadom komponentów zdjęcia dostawcy.

W Androidzie 11 i nowszych partycje system_ext i product mogą też zawierać zasady dla poszczególnych partycji. System_ext i zasady dotyczące produktów są podzielone na publiczny i prywatny, a dostawcy mogą używać parametru system_ext i atrybutu zasad, takich jak zasady systemowe.

• SYSTEM_EXT_PUBLIC_SEPOLICY_DIRS Obejmuje wyeksportowane zasady dla instancji wykorzystanie w zasadach dla danego dostawcy. Zainstalowano na partycji system_ext.
• SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS Obejmuje niezbędne zasady za działanie obrazu system_ext, ale obraz dostawcy zasady nie powinny mieć żadnej wiedzy. Zainstalowano na partycji system_ext.
• PRODUCT_PUBLIC_SEPOLICY_DIRS Obejmuje wyeksportowane zasady dla instancji wykorzystanie w zasadach dla danego dostawcy. Zainstalowano na partycji produktu.
• PRODUCT_PRIVATE_SEPOLICY_DIRS Obejmuje zasady niezbędne dla działania zdjęcia produktu, ale zasady dotyczące zdjęć dostawcy nie powinni mieć żadnej wiedzy. Zainstalowano na partycji produktu.

Obsługiwane scenariusze zasad

Na urządzeniach z Androidem 8.0 lub nowszym obraz dostawcy musi działać ze zdjęciem systemu OEM i obrazem referencyjnym systemu AOSP dostarczonym przez Google (i przekaż wartość CTS dla tego obrazu referencyjnego). Wymagania te zapewniają oddzielenie platformy od kodu dostawcy. Takie urządzenia obsługują poniższych scenariuszy.

rozszerzenia graficzne tylko od dostawcy

Przykład: dodawanie nowej usługi do domeny vndservicemanager. z obrazu dostawcy, który obsługuje procesy z obrazu dostawcy.

Podobnie jak w przypadku urządzeń z poprzednimi wersjami Androida dodaj informację o konkretnym urządzeniu dostosowanie w device/manufacturer/device-name/sepolicy Nowa zasada określająca sposób interakcji komponentów dostawcy z innymi dostawcami (tylko) komponenty powinny obejmować typy występujące tylko w device/manufacturer/device-name/sepolicy Zasady zapisane tutaj pozwalają na działanie kodu u dostawcy i nie zostaną zaktualizowane OTA działa tylko w ramach platformy i będzie obecne w połączonych zasadach na urządzeniu z referencyjnym obrazem systemu AOSP.

pomoc dotycząca obrazu dostawcy do pracy z usługą AOSP

Przykład: dodawanie nowego procesu (zarejestrowanego za pomocą hwservicemanager ze zdjęcia dostawcy), który implementuje komponent HAL zdefiniowana przez AOSP.

Podobnie jak w przypadku urządzeń z poprzednimi wersjami Androida, na konkretne urządzenia device/manufacturer/device-name/sepolicy Zasada eksportowana w ramach elementu system/sepolicy/public/ jest dostępna do użytkowania i jest wysyłane zgodnie z zasadami dostawcy. Typy i atrybuty z może być stosowana w nowych regułach określających interakcje z nowymi dane powiązane z dostawcą, zgodnie z zamieszczonym w neverallow ograniczeń. Tak jak w przypadku zgłoszenia tylko dla dostawcy, nowe zasady nie zostaną zaktualizowane w ramach platformy OTA i będzie uwzględniona w połączonych zasadach z obrazem referencyjnym systemu AOSP.

rozszerzenia z samym obrazem systemowym

Przykład: dodawanie nowej usługi (zarejestrowanej za pomocą menedżera usług) do którego mają dostęp tylko inne procesy z obrazu systemu.

Dodaj tę zasadę do system/sepolicy/private. Możesz dodać więcej procesów lub obiektów, które są włączone w obrazie systemu partnera, pod warunkiem że te nowe elementy nie muszą wchodzić w interakcję z nowymi komponentami na obrazie dostawcy (w szczególności takie procesy lub obiekty muszą w pełni funkcjonować bez zasad zdjęcia dostawcy). Zasada eksportowana przez system/sepolicy/public to Tak samo jak w przypadku rozszerzeń graficznych tylko od dostawcy. Ta zasada jest jako część obrazu systemu i można ją zaktualizować w ramach aktualizacji OTA tylko dla platformy, ale nie będzie używany przy korzystaniu z referencyjnego obrazu systemu AOSP.

obraz-dostawcy rozszerzenia, które wyświetlają rozszerzone komponenty AOSP

Przykład: nowy, inny niż AOSP HAL do użytku przez rozszerzone klienty, który istnieją też w obrazie systemu AOSP (np. w rozszerzonym serwerze systemowym).

Zasady interakcji między systemem a dostawcą muszą być uwzględnione w device/manufacturer/device-name/sepolicy jako katalog wysyłany na partycję dostawcy. Jest to podobne do powyższego przykładu dodania funkcji obsługi obrazów dostawcy z referencyjnym obrazem AOSP, z wyjątkiem zmodyfikowanych komponentów AOSP wymagają dodatkowych zasad do prawidłowego działania z resztą systemu partycji (jest to dozwolone, o ile nadal mają oni publiczny typ AOSP). etykiety).

Zasady interakcji publicznych komponentów AOSP z obrazem systemu rozszerzenia powinny zawierać się w elemencie system/sepolicy/private.

Obraz systemu które mają dostęp tylko do interfejsów AOSP.

Przykład: nowy proces systemowy inny niż AOSP musi uzyskać dostęp do HAL w z którego korzysta AOSP.

Przypomina to tylko obraz systemowy przykład rozszerzenia, z tym że nowe komponenty systemu mogą wchodzić w interakcje interfejsu system/vendor. Zasada nowego komponentu systemu musi przejdź w system/sepolicy/private, co jest dopuszczalne, pod warunkiem że jest za pomocą interfejsu utworzonego przez AOSP system/sepolicy/public (tzn. typy i atrybuty wymagane w przypadku dostępne funkcje). Zasady można uwzględnić w sekcji nie będzie mógł korzystać z innych zasad system/sepolicy/private typów lub zmian (w jakikolwiek sposób wpływający na zasady) w wyniku działania wyłącznie platformy . Te zasady mogą zostać zmienione w ramach OTA, lecz nie zostaną dostępny przy użyciu obrazu systemu AOSP (który nie będzie zawierać nowego systemu ).

obraz-dostawcy rozszerzeń, które wyświetlają nowe komponenty systemu

Przykład: dodawanie nowego kodu HAL innego niż AOSP do wykorzystania przez proces klienta bez analogu AOSP (a tym samym wymaga własnej domeny).

Podobnie jak rozszerzenia AOSP , zasady interakcji między systemem a dostawcą muszą być device/manufacturer/device-name/sepolicy katalog dostarczany na partycji dostawcy (aby zapewnić, że zasady systemowe nie znają szczegółów dotyczących konkretnego dostawcy). Ty mogą dodawać nowe typy publiczne, które rozszerzają zasady system/sepolicy/public; należy to robić wyłącznie w połączeniu istniejące zasady AOSP, czyli nie usuwać zasad publicznych AOSP. Co nowego publiczna typów, których można użyć w zasadach w system/sepolicy/private i w device/manufacturer/device-name/sepolicy

Pamiętaj, że każde dodanie do system/sepolicy/public powoduje złożoność przez ujawnienie nowej gwarancji zgodności, którą należy śledzić który podlega innym ograniczeniom. Tylko nowe typy odpowiednie reguły zezwalające można dodać w system/sepolicy/public. atrybuty i inne instrukcje dotyczące zasad nie są obsługiwane. Ponadto nowe typów publicznych nie można używać do bezpośredniego oznaczania obiektów w Zasada /vendor.

Nieobsługiwane scenariusze zasad

Urządzenia uruchamiane z Androidem 8.0 lub nowszym nie obsługują tych funkcji: scenariusz i przykłady dotyczące zasad.

Dodatkowe informacje rozszerzenia obrazu systemu, które wymagają uprawnień do nowych komponentów obrazu dostawcy, po zakończeniu aktualizacji OTA obejmującej tylko platformę.

Przykład: nowy proces inny niż AOSP, wymagający własnego zostanie dodana w następnej wersji Androida i potrzebuje dostępu do nowego, HAL inna niż AOSP.

Podobne do nowy (innych niż AOSP) w komponentach systemu i dostawcy, z wyjątkiem nowego systemu jest wprowadzany w OTA działa tylko w ramach platformy. Chociaż nowy typ można dodać do zasady w system/sepolicy/public, obecne zasady dostawcy nie są znane nowego typu, ponieważ śledzi tylko zasady publiczne systemu Android 8.0. AOSP udostępnia to, udostępniając zasoby dostarczone przez dostawcę za pomocą atrybutu (np. hal_foo), ale jako atrybut rozszerzenia partnera nie obsługiwana w: system/sepolicy/public, ta metoda jest niedostępna w zasadom dostawcy. Dostęp musi być zapewniany przez istniejący wcześniej typ publiczny.

Przykład: zmiana w procesie systemowym (AOSP lub nie-AOSP) musi być zmienić sposób jego interakcji z nowym komponentem dostawcy innego niż AOSP.

Zasady dotyczące obrazu systemu muszą być napisane bez znajomości na podstawie ustawień dostawcy. Zasady dotyczące określonych interfejsów w AOSP zostały więc ujawnione za pomocą atrybutów w atrybutach system/sepolicy/public, tak aby zasada dostawcy mogła zaakceptować przyszłe zasady systemowe wykorzystujące te atrybuty. Pamiętaj jednak: rozszerzenia atrybutów w atrybutach system/sepolicy/public nie są obsługiwane, więc wszystkie zasady określają sposób interakcji komponentów systemu z nowymi komponentami dostawców (który nie jest obsługiwany przez atrybuty już w AOSP system/sepolicy/public) musi być w device/manufacturer/device-name/sepolicy Oznacza to, że typy systemów nie mogą się zmieniać dozwolony dostęp dla typów dostawców w ramach OTA tylko dla platformy.