Android Open Source Project (AOSP) zapewnia solidną podstawę dla aplikacje i usługi, które są wspólne dla wszystkich urządzeń z Androidem. Współtwórcy AOSP regularnie ulepszają te zasady. Oczekiwana jest podstawowa zasada które stanowią 90–95% ostatecznych zasad na urządzeniu dostosowania, które stanowią pozostałe 5–10%. Ten artykuł koncentruje się na dostosowania do konkretnych urządzeń, tworzenia zasad dla konkretnego urządzenia oraz pułapek, których należy unikać.
Wyświetlenie urządzenia
Podczas tworzenia zasad dla konkretnego urządzenia wykonaj te czynności.
Uruchom w trybie mniej rygorystycznym
Gdy urządzenie jest w trybie mniej rygorystycznym, odmowy są rejestrowane, ale nie są egzekwowane. Tryb mniej rygorystyczny jest ważny dla 2 osób przyczyny:
- Tryb mniej rygorystyczny zapewnia, że wywołanie zasad nie opóźnia innych działań na urządzeniu.
- Wymuszona odmowa może maskować inne odmowy. Na przykład dostęp do plików zwykle obejmuje przeszukanie katalogu, otwarcie pliku, a potem jego odczytanie. W w trybie wymuszania wystąpi tylko odmowa przeszukania katalogu. Tryb mniej rygorystyczny daje gwarancję, że będą widoczne wszystkie odmowy.
Najprostszym sposobem na przełączenie urządzenia w tryb mniej rygorystyczny jest użycie
polecenie jądra systemu
. Można to dodać do pliku BoardConfig.mk
na urządzeniu:
platform/device/<vendor>/<target>/BoardConfig.mk
Po zmodyfikowaniu wiersza poleceń wpisz make clean
, a potem
make bootimage
i zainstaluj nowy obraz rozruchowy.
Następnie potwierdź tryb mniej rygorystyczny za pomocą tych instrukcji:
adb shell getenforce
Dwa tygodnie to rozsądny czas, aby przejść do globalnego mniej rygorystycznego zachowania. Po rozwiązaniu większości odmów wróć do trybu egzekwowania, i rozwiązuj je na bieżąco. Domeny, w których wciąż pojawiają się odmowy lub usługi w trakcie prac programistycznych można tymczasowo przełączyć w tryb mniej rygorystyczny, jak najszybciej wrócić do trybu egzekwowania.
Wymuszaj wcześnie
W trybie egzekwowania odmowy są zarówno rejestrowane, jak i egzekwowane. Najlepiej poćwicz, aby jak najszybciej przełączyć urządzenie w tryb egzekwowania zasad. Oczekiwanie na stworzenie i egzekwowanie zasad dla konkretnego urządzenia powoduje często wystąpienie błędów w produkcie i co pogarsza wrażenia użytkowników. Zacznij z wyprzedzeniem, aby wziąć udział testowanie wewnętrzne i dokładnie sprawdzić działanie naszych funkcji w czasie rzeczywistym. Uruchamiam wczesnych testów i w ten sposób umożliwia podejmowanie decyzji projektowych. I odwrotnie: wyłącznie na podstawie zaobserwowanych odmów. Użyj tej czas przeprowadzić audyt zabezpieczeń urządzenia i zgłosić błędy dotyczące jego działania. co nie powinno być dozwolone.
Usuń lub usuń istniejącą zasadę
Istnieje wiele uzasadnionych powodów, dla których warto utworzyć zasady dla konkretnego urządzenia na nowym urządzeniu. Należą do nich:
- Kontrola zabezpieczeń
- Zbyt mało restrykcyjne zasady
- Zmniejszenie rozmiaru zasad
- Zasady dotyczące nieaktywnych reklam
Reagowanie na odmowy dostępu do usług podstawowych
Odmowy generowane przez usługi podstawowe są zwykle eliminowane przez oznaczanie plików etykietami. Na przykład:
avc: denied { open } for pid=1003 comm=”mediaserver” path="/dev/kgsl-3d0” dev="tmpfs" scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0 tclass=chr_file permissive=1 avc: denied { read write } for pid=1003 name="kgsl-3d0" dev="tmpfs" scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0 tclass=chr_file permissive=1
jest w pełni rozwiązany dzięki poprawnemu oznaczeniu atrybutu /dev/kgsl-3d0
. W
w tym przykładzie tcontext
to device
. To daje
w którym wszystko w polu /dev
otrzymuje
„
urządzenie”, chyba że zostanie przypisana bardziej szczegółowa etykieta. Wystarczy zaakceptować
dane wyjściowe z
audit2allow
w tym przypadku doszłoby do nieprawidłowej i zbyt mało restrykcyjnej reguły.
Aby rozwiązać tego rodzaju problem, nadaj plikowi bardziej szczegółową etykietę, która: ten przypadek jest gpu_device. Nie są potrzebne żadne dodatkowe uprawnienia, ponieważ Mediaserver ma już w podstawowej zasadzie uprawnienia niezbędne do dostępu do gpu_device.
Inne pliki przeznaczone na konkretne urządzenia, które powinny być oznaczone etykietami z typami wstępnie zdefiniowanych w podstawowe zasady:
- blokuj urządzenia
- urządzenia audio
- urządzenia wideo
- czujniki
- NFC
- urządzenie_gps
- pliki w katalogu /sys
- pliki w /proc
Ogólnie rzecz biorąc, przyznawanie uprawnień etykietom domyślnym jest niewłaściwe. Wiele z tych Uprawnienia nie są akceptowane przez neverallow, ale nawet jeśli nie jest to wyraźnie zabronione, sprawdzoną metodą jest podawanie określonych .
Oznacz nowe usługi i adres odmowy
Uruchomione w ten sposób usługi muszą działać we własnych domenach SELinux. Poniższy przykład umieszcza usługę „foo” w własnej domenie SELinux i przyznaje jej uprawnień.
Usługa jest uruchamiana w
init.device.rc
plik jako:
service foo /system/bin/foo class core
- Utwórz nową domenę „foo”
Tworzenie pliku
device/manufacturer/device-name/sepolicy/foo.te
z następującą treścią:# foo service type foo, domain; type foo_exec, exec_type, file_type; init_daemon_domain(foo)
To jest początkowy szablon domeny foo SELinux, do której może dodawać reguły oparte na konkretnych operacjach wykonywanych przez dany plik wykonywalny.
- Etykieta
/system/bin/foo
Dodaj następujące elementy do
device/manufacturer/device-name/sepolicy/file_contexts
:/system/bin/foo u:object_r:foo_exec:s0
Dzięki temu plik wykonywalny jest odpowiednio oznaczony etykietą, tak aby SELinux uruchamiał w odpowiedniej domenie.
- Utwórz i flashuj obrazy rozruchowe i systemowe.
- Sprecyzuj reguły SELinux.
Aby określić wymagane uprawnienia, użyj odmów. audit2allow zawiera dobre wytyczne, ale należy je stosować tylko przy określaniu zasad pisanie. Nie kopiuj danych wyjściowych.
Przełącz z powrotem na tryb egzekwowania
Rozwiązywanie problemów jest dozwolone w trybie mniej rygorystycznym, ale powrót do egzekwowania jak najszybciej.
Typowe błędy
Oto kilka rozwiązań najczęstszych błędów, które mogą wystąpić podczas pisania zasad dla poszczególnych urządzeń.
Nadużywanie negacji
Poniższa przykładowa reguła przypomina zablokowanie drzwi wejściowych, ale pozostawienie Otwarte okna:
allow { domain -untrusted_app } scary_debug_device:chr_file rw_file_perms
Intencja jest jasna: wszyscy oprócz aplikacji innych firm mogą mieć dostęp do debugowania urządzenia.
Reguła jest pod kilkoma względami błędna. Wykluczenie: untrusted_app
jest proste, ponieważ wszystkie aplikacje mogą opcjonalnie uruchamiać usługi
isolated_app
. Podobnie, jeśli nowe domeny dla aplikacji innych firm
zostanie dodany do AOSP, będzie też miał dostęp do usługi scary_debug_device
.
Reguła jest zbyt mało restrykcyjna. Większość domen nie skorzystaje na
dostęp do narzędzia do debugowania. Reguła powinna być tak napisana, aby zezwalała na dostęp tylko
które wymagają dostępu.
Funkcje debugowania w wersji produkcyjnej
Funkcje debugowania nie powinny być dostępne w kompilacjach produkcyjnych ani ich .
Najprostszą alternatywą jest zezwolenie na funkcję debugowania tylko wtedy, gdy SELinux jest
wyłączone w kompilacjach eng/userdebug, takich jak adb root
czy
adb shell setenforce 0
Innym bezpiecznym rozwiązaniem jest objęcie uprawnień do debugowania w pliku userdebug_or_eng.
Powiększenie rozmiaru zasad
Charakterystyka zasad SEAndroid in the Wild opisują niepokojący trend w zwiększaniu liczby dostosowań zasad dotyczących urządzeń. Zasady dla poszczególnych urządzeń powinny uwzględniać 5–10% wszystkich zasad uruchomionych na urządzenia. Dostosowania o wartości powyżej 20%niemal na pewno obejmują ponad z podwyższonymi uprawnieniami oraz zasadami martwych domen.
Zbyt duża zasada:
- Dwukrotnie uderza w pamięci, ponieważ zasada znajduje się na dysku RAM wczytywanego do pamięci jądra systemu operacyjnego.
- Powoduje to niepotrzebne miejsce na dysku, ponieważ wymaga użycia większego obrazu rozruchowego.
- Wpływa na czas wyszukiwania zasady środowiska wykonawczego.
Poniższy przykład przedstawia dwa urządzenia, w przypadku których stanowiła 50% i 40% zasad na urządzeniu. Zmodyfikowanie zasad wiąże się ze znacznymi ulepszeniami bezpieczeństwa bez utraty funkcjonalności. poniżej. (Aby porównać urządzenia AOSP, uwzględniono Shamu i Flounder).
Rysunek 1. Porównanie w zależności od urządzenia rozmiar zasady po kontroli zabezpieczeń.
W obu przypadkach zasady zostały drastycznie ograniczone pod względem rozmiaru i liczby.
uprawnień. Spadek rozmiaru zasad jest niemal całkowicie spowodowany usunięciem
uprawnień, z których wiele było prawdopodobnie generowanych przez reguły
audit2allow
, które zostały bezprecedensowo dodane do zasady. Rozładowana
domeny były też problemem na obu urządzeniach.
Przyznaję funkcję dac_override
Odmowa dac_override
oznacza, że proces naruszający zasady
próba uzyskania dostępu do pliku z nieprawidłowymi uprawnieniami użytkownika/grupy/świata w systemie UNix.
Właściwym rozwiązaniem prawie nigdy nie jest przyznanie uprawnienia dac_override
.
Zamiast tego
zmienić uprawnienia systemu uniksowego do pliku lub procesu. Niektóre domeny, takie jak
init
, vold
i installd
naprawdę potrzebują
z możliwością zastępowania uprawnień dostępu do plików w innych procesach w systemie Unix.
Zobacz bloga Dana Walsha
.