Android zdecydowanie zachęca producentów OEM do dokładnego testowania implementacji SELinux. Podczas wdrażania SELinux producenci powinni najpierw zastosować nowe zasady do testowego zbioru urządzeń.
Po zastosowaniu nowej zasady sprawdź, czy SELinux działa w odpowiednim trybie na urządzeniu. Aby to zrobić, uruchom polecenie getenforce.
Wyświetla globalny tryb SELinux: Enforcing (Wymuszenie) lub Permissive (Zezwalanie). Aby określić tryb SELinux dla każdej domeny, musisz sprawdzić odpowiednie pliki lub uruchomić najnowszą wersję sepolicy-analyze z odpowiednią flagą (-p), która znajduje się w
/platform/system/sepolicy/tools/.
Odmowa odczytu
Sprawdź, czy nie występują błędy, które są kierowane jako dzienniki zdarzeń do dmesg i logcat oraz są widoczne lokalnie na urządzeniu. Producenci powinni sprawdzić dane wyjściowe SELinux (dmesg) na tych urządzeniach i dostosować ustawienia przed publiczną publikacją w trybie zezwalającym, a potem przejść do trybu wymuszającego. Wiadomości z dziennika SELinux zawierają avc:, więc można je łatwo znaleźć za pomocą grep. Aby przechwycić bieżące logi odmowy, uruchom cat /proc/kmsg. Aby przechwycić logi odmowy z poprzedniego uruchomienia, uruchom cat /sys/fs/pstore/console-ramoops.
Aby uniknąć przeciążania dzienników, po zakończeniu uruchamiania system ogranicza częstotliwość wyświetlania komunikatów o błędach SELinux. Aby mieć pewność, że widzisz wszystkie istotne wiadomości, możesz wyłączyć tę funkcję, uruchamiając adb shell auditctl -r 0.
Dzięki tym wynikom producenci mogą łatwo określić, kiedy użytkownicy lub komponenty systemu naruszają zasady SELinux. Producenci mogą naprawić to złe zachowanie, wprowadzając zmiany w oprogramowaniu lub zasadach SELinux albo w obu tych elementach.
Te komunikaty wskazują, które procesy nie będą działać w trybie wymuszania i dlaczego. Oto przykład:
avc: denied { connectto } for pid=2671 comm="ping" path="/dev/socket/dnsproxyd"
scontext=u:r:shell:s0 tcontext=u:r:netd:s0 tclass=unix_stream_socket
Interpretuj te dane wyjściowe w ten sposób:
-
{ connectto }powyżej przedstawia podejmowane działanie. Wraz ztclassna końcu (unix_stream_socket) informuje, co zostało zrobione. W tym przypadku coś próbowało nawiązać połączenie z gniazdem strumieniowym Unixa. -
scontext (u:r:shell:s0)informuje, jaki kontekst zainicjował działanie. W tym przypadku jest to coś, co działa jako powłoka. -
tcontext (u:r:netd:s0)zawiera kontekst celu działania. W tym przypadku jest to unix_stream_socket należący donetd. -
comm="ping"u góry zawiera dodatkowy podpowiedź dotyczącą tego, co było wykonywane w momencie wygenerowania odmowy. W tym przypadku jest to całkiem dobry wskazówek.
Inny przykład:
adb shell su root dmesg | grep 'avc: '
Urządzenie wyjściowe:
<5> type=1400 audit: avc: denied { read write } for pid=177
comm="rmt_storage" name="mem" dev="tmpfs" ino=6004 scontext=u:r:rmt:s0
tcontext=u:object_r:kmem_device:s0 tclass=chr_file
Oto najważniejsze elementy tej odmowy:
- Działanie – próba wykonania działania jest wyróżniona w nawiasach:
read writelubsetenforce. - Uczestnik – wpis
scontext(kontekst źródła) reprezentuje uczestnika, w tym przypadku demonarmt_storage. - Obiekt – wpis
tcontext(kontekst docelowy) reprezentuje obiekt, na którym wykonywana jest operacja, w tym przypadku kmem. - Wynik – wpis
tclass(klasa docelowa) wskazuje typ obiektu, na którym wykonywane jest działanie, w tym przypadkuchr_file(urządzenie znakowe).
Wydumpowanie stosów użytkownika i jądra
W niektórych przypadkach informacji zawartych w logu zdarzeń jest za mało, aby można było wskazać źródło odmowy. Aby lepiej zrozumieć, dlaczego doszło do odrzucenia, warto często zebrać łańcuch wywołań, w tym dotyczące jądra i przestrzeni użytkownika.
Najnowsze jądra definiują punkt śledzenia o nazwie avc:selinux_audited. Aby włączyć ten punkt śledzenia i utworzyć łańcuch wywołań, użyj na urządzeniu z Androidem opcji simpleperf.
Obsługiwana konfiguracja
- Jądro Linuksa >= 5.10, w szczególności gałęzie mainline i android12-5.10 jądra wspólnego Androida.
Obsługiwana jest też gałąź android12-5.4. Aby sprawdzić, czy punkt trasy jest zdefiniowany na urządzeniu, użyj polecenia
simpleperf:adb root && adb shell simpleperf list | grep avc:selinux_audited. W przypadku innych wersji jądra możesz wybrać commity dd81662 i 30969bc. - Należy mieć możliwość odtworzenia zdarzenia, które debugujesz. Zdarzenia uruchamiania nie są obsługiwane przez simpleperf, ale nadal możesz ponownie uruchomić usługę, aby wywołać zdarzenie.
Rejestrowanie łańcucha wywołań
Najpierw należy zarejestrować zdarzenie za pomocą funkcji simpleperf record:
adb shell -t "cd /data/local/tmp && su root simpleperf record -a -g -e avc:selinux_audited"
Następnie powinno zostać wywołane zdarzenie, które spowodowało odrzucenie. Następnie nagrywanie powinno zostać zatrzymane. W tym przykładzie próbka zostałaby zarejestrowana za pomocą funkcji Ctrl-c:
^Csimpleperf I cmd_record.cpp:751] Samples recorded: 1. Samples lost: 0.
Na koniec możesz użyć simpleperf report, aby sprawdzić zarejestrowany ślad stosu.
Na przykład:
adb shell -t "cd /data/local/tmp && su root simpleperf report -g --full-callgraph"
[...]
Children Self Command Pid Tid Shared Object Symbol
100.00% 0.00% dmesg 3318 3318 /apex/com.android.runtime/lib64/bionic/libc.so __libc_init
|
-- __libc_init
|
-- main
toybox_main
toy_exec_which
dmesg_main
klogctl
entry_SYSCALL_64_after_hwframe
do_syscall_64
__x64_sys_syslog
do_syslog
selinux_syslog
slow_avc_audit
common_lsm_audit
avc_audit_post_callback
avc_audit_post_callback
Powyższy łańcuch wywołań to zjednoczony łańcuch wywołań jądra i przestrzeni użytkownika. Zapewnia on lepszy wgląd w przepływ kodu, ponieważ rozpoczyna śledzenie od przestrzeni użytkownika aż do jądra, gdzie następuje odmowa. Więcej informacji o simpleperf znajdziesz w pliku pomocy z poleceniami Simpleperf.
Przełącz na tryb permisywny
Wymuszanie SELinux można wyłączyć za pomocą adb w wersjach userdebug lub eng. Aby to zrobić, najpierw przełącz ADB na root, wykonując polecenie adb root. Aby wyłączyć SELinux, uruchom:
adb shell setenforce 0
Lub w wierszu poleceń jądra (podczas wczesnego uruchamiania urządzenia):
androidboot.selinux=permissiveandroidboot.selinux=enforcing
Możesz też użyć bootconfigu w Androidzie 12:
androidboot.selinux=permissiveandroidboot.selinux=enforcing
Używanie audit2allow
Narzędzie audit2allow przekształca zaprzeczenia dmesg w odpowiednie oświadczenia o zasadach SELinux. Dzięki temu można znacznie przyspieszyć rozwój SELinux.
Aby go użyć, uruchom:
adb pull /sys/fs/selinux/policyadb logcat -b events -d | audit2allow -p policy
Należy jednak zachować ostrożność i sprawdzać każde potencjalne dodanie pod kątem nadmiernych uprawnień. Na przykład podanie audit2allow za pomocą rmt_storage zaprzeczenia pokazanego wcześniej powoduje wyświetlenie w SELinux następującego oświadczenia:
#============= shell ==============
allow shell kernel:security setenforce;
#============= rmt ==============
allow rmt kmem_device:chr_file { read write };
Dałoby to rmt możliwość zapisywania pamięci jądra, co jest poważną luką w zabezpieczeniach. Często instrukcje audit2allow są tylko punktem wyjścia. Po zastosowaniu tych instrukcji może być konieczne zmodyfikowanie domeny źródłowej i etykiety docelowej oraz włączenie odpowiednich makr, aby uzyskać dobre zasady. Czasami odrzucenie nie powinno powodować żadnych zmian w zasadach. W takim przypadku należy zmienić aplikację, która narusza zasady.