Zapisywanie zasady SELinux

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

1. 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.

2. 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.

3. Utwórz i flashuj obrazy rozruchowe i systemowe.
4. 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 .