Zgodność zasad

Ten artykuł opisuje, jak Android radzi sobie z problemami ze zgodnością zasad z OTA platformy, gdzie ustawienia SELinux nowej platformy mogą różnić się od ustawień starego dostawcy Ustawienia SELinux.

Konstrukcja zasad SELinux w systemie Treble uwzględnia rozróżnienie binarne. między zasadami dotyczącymi platformy i dostawców. schemat zmienia się w bardziej skomplikowane, jeśli partycje dostawcy generują zależności, takie jak platform < vendor < oem.

W Androidzie 8.0 i nowszych zasada globalna SELinux jest podzielona na prywatne i komponentów publicznych. Komponenty publiczne składają się z zasady i powiązanych które z gwarancją będą dostępne dla różnych wersji platformy. Twórcy zasad będą mogli je odczytać, aby umożliwić dostawcom plik zasad dostawcy, który w połączeniu z zasadami udostępnianymi przez platformę w pełni funkcjonalne zasady urządzenia.

  • Na potrzeby obsługi wersji wyeksportowana zasada publiczna platformy będzie zapisana jako atrybuty.
  • Aby ułatwić pisanie zasad, wyeksportowane typy zostaną przekształcone w atrybuty wersjonowane w ramach procesu tworzenia zasad. Publiczna typy mogą być również używane bezpośrednio w decyzjach dotyczących oznaczania etykietami dostarczanych przez dostawcę. plików kontekstowych.

Android tworzy mapowanie między eksportowanymi typami betonów na platformie zasady i odpowiednie atrybuty z obsługą wersji dla każdej platformy wersji. Dzięki temu, gdy obiekty są oznaczone etykietą z typem, nie zakłóca działania, które gwarantuje platforma publiczna w poprzedniej wersji wersji. Mapowanie jest utrzymywane przez dbanie o aktualność pliku mapowania w przypadku każdej wersji platformy, która zachowuje informacje o członkostwie w przypadku każdej typ wyeksportowany w zasadzie publicznej.

Własność obiektu i oznaczanie etykietami

Podczas dostosowywania zasad w Androidzie 8.0 lub nowszym własność musi być jasno określona dla każdego obiektu, aby oddzielić zasady platformy i dostawcy. Na przykład, jeśli etykiety dostawcy /dev/foo i platforma, a następnie etykiety /dev/foo podczas kolejnych aktualizacji OTA, działanie będzie nieokreślone. Dla: SELinux, to jest wynikiem kolizji etykiet. Węzeł urządzenia może mieć tylko 1 etykieta stosowana jako ostatnia. W rezultacie:

  • Procesy, które potrzebują dostępu do niewłaściwie zastosowanej etykiety, będą utracą dostęp do zasobu.
  • Procesy, które uzyskują dostęp do pliku, mogą przestać działać, ponieważ nieprawidłowy zapis węzeł urządzenia.

Właściwości systemowe mogą też powodować kolizje nazw, niezdefiniowane zachowanie w systemie (oraz etykiety SELinux). Kolizje między platformami a etykietami dostawcy może wystąpić dla każdego obiektu z SELinux , łącznie z właściwościami, usługami, procesami, plikami i gniazdami. Aby unikać te problemy, jasno określają własność tych obiektów.

Nie tylko kolizje etykiet mogą powodować konflikty między nazwami typów/atrybutów SELinux. Konflikt nazw typów i atrybutów zawsze prowadzi do błędu kompilatora zasad.

Podział nazw typów/atrybutów

W SELinux nie można składać wielu deklaracji tego samego typu/atrybutu. Zasady ze zduplikowanymi deklaracjami nie będą skompilowane. Aby unikać pisania i konflikty nazw atrybutów, wszystkie deklaracje dostawców powinny mieć przestrzeń nazw zaczynając od vendor_. 

type foo, domain; → type vendor_foo, domain;

Właściwość systemowa proces oznaczania etykietami prawa własności

Unikanie kolizji z etykietami najlepiej rozwiązać za pomocą przestrzeni nazw właściwości. Do mogą łatwo identyfikować właściwości platformy i unikać konfliktów nazw przy zmianie nazw lub dodawania wyeksportowanych właściwości platformy. Upewnij się, że wszystkie usługi dostawcy własne prefiksy:

Typ nieruchomości Dopuszczalne prefiksy
sterowanie właściwościami ctl.vendor.
ctl.start$vendor.
ctl.stop$vendor.
init.svc.vendor.
z możliwością zapisu i odczytu vendor.
tylko do odczytu ro.vendor.
ro.boot.
ro.hardware.
trwała persist.vendor.

Dostawcy mogą nadal korzystać z narzędzia ro.boot.* (pochodzącego z jądra) cmdline) i ro.hardware.* (oczywista właściwość związana ze sprzętem).

Wszystkie usługi dostawcy w inicjowanych plikach rc powinny mieć parametr vendor. dla usług w plikach rc inicjowania na partycjach innych niż systemowe. Podobne reguły są zastosowano do etykiet SELinux właściwości dostawcy (vendor_) dla usług dostawcy).

Własność pliku

Zapobieganie kolizji plików jest trudne, ponieważ platforma i dostawca te zasady często dostarczają etykiety dla wszystkich systemów plików. W przeciwieństwie do nazewnictwa typów rozmieszczenie plików z nazwami jest niepraktyczne, ponieważ wiele z nich jest tworzonych jądro. Aby zapobiec tym kolizji, postępuj zgodnie ze wskazówkami dotyczącymi nazewnictwa systemów plików w tej sekcji. W przypadku Androida 8.0 są to zalecenia bez kwestii technicznych dotyczących egzekwowania zasad. W przyszłości te rekomendacje będą egzekwowane przez Vendor Test Suite (VTS).

System (/system)

Tylko obraz systemu może zawierać etykiety dla komponentów /system przez file_contexts, service_contexts itp. Jeśli etykiety dla /system komponentów zostało dodanych w zasadzie /vendor, Aktualizacja OTA w ramach tylko platformy może być niemożliwa.

Dostawca (/dostawca)

Zasada AOSP SELinux oznacza już części partycji vendor etykietami platforma współdziała z nią, co umożliwia pisanie reguł SELinux dla platformy procesów, które pozwalają rozmawiać z innymi częściami aplikacji vendor i uzyskiwać do nich dostęp partycji danych. Przykłady:

Ścieżka /vendor Etykieta dostarczona przez platformę Przetwarzanie platformy w zależności od etykiety
/vendor(/.*)? vendor_file Wszyscy klienci HAL w ramach platformy, ueventd itp.
/vendor/framework(/.*)? vendor_framework_file dex2oat, appdomain itp.
/vendor/app(/.*)? vendor_app_file dex2oat, installd, idmap itp.
/vendor/overlay(/.*) vendor_overlay_file system_server, zygote, idmap itp.

W związku z tym muszą być przestrzegane określone zasady (egzekwowane przez neverallows) podczas oznaczania dodatkowych plików w folderze vendor partycja:

  • vendor_file musi być etykietą domyślną dla wszystkich plików w vendor partycja. Zasady platformy wymagają tego, aby mieć dostęp przekazujących implementacji HAL.
  • Wszystkie nowe exec_types zostały dodane w partycji vendor za pośrednictwem SEPolicy dostawcy musi mieć atrybut vendor_file_type. Ten jest wymuszane na zasadzie „Nigdy nie zezwalaj”.
  • Aby uniknąć konfliktów z przyszłymi aktualizacjami platformy lub platformy, unikaj oznaczania etykietami pliki inne niż exec_types w partycji vendor.
  • Wszystkie zależności bibliotek w przypadku kluczy HAL z tym samym procesem zidentyfikowanym przez AOSP muszą być oznaczone jako same_process_hal_file.

Procfs (/proc)

Etykiety plików w folderze /proc mogą być oznaczone tylko etykietą genfscon . W Androidzie 7.0 platforma i dostawca zasada używała genfscon do oznaczania plików w folderze procfs etykietami.

Zalecenie: tylko etykiety zasad platformy /proc. Jeśli procesy vendor wymagają dostępu do plików w lokalizacji /proc, które są obecnie oznaczone etykietą domyślną (proc), zasadą dostawcy nie powinny oznaczać ich wyraźnie, lecz zamiast tego powinny używać ogólnego tagu Aby dodać reguły dla domen dostawców, wpisz proc. Dzięki temu platforma aby uwzględnić przyszłe interfejsy jądra udostępniane przez procfs i wyraźnie oznacz je etykietą w razie potrzeby.

Debugfs (/sys/kernel/debug)

Debugfs można oznaczyć etykietami zarówno w file_contexts, jak i genfscon Na Androidzie od 7.0 do 10 etykieta platformy i dostawcy debugfs

Na Androidzie 11 aplikacji debugfs nie można dostępnych lub podłączonych na urządzeniach produkcyjnych. Producenci urządzeń powinni usuń debugfs.

Ślady (/sys/kernel/debug/tracing)

Tracefs można oznaczyć etykietami zarówno w file_contexts, jak i genfscon W Androidzie 7.0 tylko etykiety platformy tracefs

Zalecenie: tylko platforma może oznaczyć etykietą tracefs.

Sysfs (/sys)

Pliki w folderze /sys mogą być oznaczone jednocześnie etykietą file_contexts i genfscon. W Androidzie 7.0 zarówno platforma, jak i dostawca używają file_contexts i genfscon, aby oznaczyć pliki etykietami w sysfs

Zalecenie: platforma może oznaczyć etykietą sysfs węzłów, które nie są związane z konkretnymi urządzeniami. W przeciwnym razie tylko dostawca może oznaczać pliki etykietami.

tmpfs (/dev)

Pliki w folderze /dev mogą mieć etykiety file_contexts. W Android 7.0. Są tu zarówno pliki etykiet platformy, jak i dostawcy.

Zalecenie: dostawca może oznaczać etykietami tylko pliki w /dev/vendor (np. /dev/vendor/foo, /dev/vendor/socket/bar).

Rootfs (/)

Pliki w folderze / mogą mieć etykiety file_contexts. Na Androidzie 7.0, są tu zarówno pliki etykiet platformy, jak i dostawcy.

Zalecenie: tylko system może oznaczać pliki etykietami w trybie /.

Dane (/data)

Dane są oznaczane etykietami za pomocą kombinacji tych atrybutów: file_contexts i seapp_contexts

Zalecenie: nie zezwalaj na oznaczanie dostawców poza organizację /data/vendor Tylko platforma może oznaczyć etykietą inne części /data

Atrybuty zgodności

Zasada SELinux dotyczy interakcji między typami źródłowymi i docelowymi w określonych klasy i uprawnienia obiektów. Dotyczy wszystkich obiektów (procesów, plików itp.) przez zasadę SELinux mogą mieć tylko jeden typ, ale ten typ może mieć wiele .

Zasady sprowadza się głównie do istniejących typów: 

allow source_type target_type:target_class permission(s);

Jest to możliwe, ponieważ zasady zostały napisane z uwzględnieniem wszystkich rodzajów wiedzy. Pamiętaj jednak: jeśli zasady dostawcy i zasady platformy używają określonych typów, a etykieta atrybutu określonych zmian obiektów tylko w jednej z tych zasad, druga może zawierać na których wcześniej opierało się uzyskanie lub utratę dostępu. Na przykład: 

File_contexts:
/sys/A   u:object_r:sysfs:s0
Platform: allow p_domain sysfs:class perm;
Vendor: allow v_domain sysfs:class perm;

Można zmienić na: 

File_contexts:
/sys/A   u:object_r:sysfs_A:s0

Chociaż zasady dostawcy pozostają takie same, v_domain utraci dostęp z powodu braku zasad dla nowych: sysfs_A typu.

Definiując zasady w postaci atrybutów, możemy nadać bazowemu obiektowi z atrybutem odpowiadającym zasadom zarówno na platformie, jak i w kod dostawcy. Można to zrobić dla wszystkich typów, aby skutecznie utworzyć attribute-policy, w którym nigdy nie używa się konkretnych typów betonu. W praktyce jest to wymagane tylko w przypadku tych części zasad, które nakładają się na użytkowników platformy. i dostawcy, którzy zostali zdefiniowani i zaprezentowani zgodnie z zasadami publicznymi dotyczącymi platformy. które wchodzą w skład zasad dotyczących dostawców.

Definiowanie polityki publicznej jako atrybutów z obsługą wersji spełnia 2 zasady cele związane ze zgodnością:

  • Upewnij się, że kod dostawcy nadal działa po aktualizacji platformy. Otrzymuje się przez dodanie atrybutów do typów betonu dla obiektów odpowiadających na których opierał się kod dostawcy, zachowując dostęp.
  • Możliwość wycofania zasad. Osiągnięcie przez wyraźnie dzieląc zestawy zasad na atrybuty, które można usunąć zaraz po nie jest już obsługiwana. Programowanie może będzie więc działać na platformie, pamiętając, że stara zasady zasadom dostawcy i zostaną automatycznie usunięte po uaktualnieniu.

Zapis zasad

Aby nie wymagać wiedzy o konkretnych zmianach wersji witryny w celu opracowywania zasad, Android 8.0 zawiera mapowanie typów zasad i ich atrybutów. Mapowany jest typ foo , aby atrybut foo_vN, gdzie N to na którą wersję docelową. vN odpowiada PLATFORM_SEPOLICY_VERSION – zmienna kompilacji i ma postać MM.NN, gdzie MM odpowiada numerowi pakietu SDK platformy a NN to wersja dla sepolicy platformy.

Atrybuty w zasadzie publicznej nie mają wersji, ale występują jako interfejs API w które zasady platformy i dostawców mogą utworzyć, aby utrzymać interfejs między tymi usługami. partycje są stabilne. Zapisujący zasady dotyczące platformy i dostawcy mogą nadal zapisywać w niezmienionej formie.

Zasada dotycząca platformy publiczna wyeksportowane jako allow source_foo target_bar:class perm; jest objęta zasadą dotyczącą dostawcy. W trakcie compilation (zawierająca odpowiedniej wersji) zostanie ona przekształcona w zasady, które zostaną dostawcy urządzenia (widocznego w przekształconym polu Common Intermediate) Język (CIL): 

 (allow source_foo_vN target_bar_vN (class (perm)))

Zasady dostawcy nigdy nie wyprzedzają platformy, więc nie powinno się przejmować wcześniejszych wersji. Zasady platformy muszą jednak wiedzieć, jak daleko wstecz odpowiada dostawca jest zasada, uwzględnij atrybuty dla jej typów oraz ustaw zasadę odpowiadającą atrybutów z obsługą wersji.

Różnice zasad

Automatyczne tworzenie atrybutów przez dodanie _vN na końcu każdego typu nie działa bez mapowania atrybutów na typy w różnych wersjach. różnice Android tworzy mapowanie między wersjami atrybutów i mapowania typów na te atrybuty. Odbywa się to we wcześniej wspomnianym mapowaniu pliki z instrukcjami, takimi jak (CIL): 

(typeattributeset foo_vN (foo))

Uaktualnienia platformy

W sekcji poniżej znajdziesz szczegółowe informacje o sytuacjach związanych z uaktualnieniem platformy.

Te same typy

Ten scenariusz występuje, gdy obiekt nie zmienia etykiet w wersjach zasady. Jest taka sama w przypadku typów źródła i celu. Można ją zobaczyć w tabeli /dev/binder, który jest oznaczony etykietą binder_device we wszystkich wersji. W przekształconych zasadach jest to reprezentowane w ten sposób: 

binder_device_v1 … binder_device_vN

Przy uaktualnianiu z v1 → v2 zasady dotyczące platformy muszą zawierają: 

type binder_device; -> (type binder_device) (in CIL)

W pliku mapowania w wersji 1 (CIL): 

(typeattributeset binder_device_v1 (binder_device))

W pliku mapowania w wersji 2 (CIL): 

(typeattributeset binder_device_v2 (binder_device))

W zasadach dostawcy w wersji 1 (CIL): 

(typeattribute binder_device_v1)
(allow binder_device_v1 …)

W zasadach dostawcy w wersji 2 (CIL): 

(typeattribute binder_device_v2)
(allow binder_device_v2 …)
Nowe typy

Ten scenariusz występuje, gdy platforma dodała nowy typ, co może się zdarzyć podczas dodawania nowych funkcji lub wzmacniania zasad.

  • Nowa funkcja. Gdy typ oznacza oznaczenie obiektu, który został które wcześniej nie istniało (np. w przypadku nowego procesu usługi), kod dostawcy nie został nie wchodzą w interakcję bezpośrednio z nim, więc nie istnieją żadne powiązane z nim zasady. Nowy atrybut odpowiadający typowi nie ma atrybutu w poprzednim wersji, więc nie potrzebują wpisu w kierowaniu pliku mapowania, wersji.
  • Wzmocnienie zasad. Gdy typ reprezentuje zasadę wzmocnienie, nowy atrybut typu musi być powiązany z łańcuchem atrybutów odpowiadająca poprzedniej (podobnie jak w poprzednim przykładzie, /sys/A od sysfs do sysfs_A). Dostawca korzysta z reguły umożliwiającej dostęp do sysfs i wymaga , aby uwzględnić ją jako atrybut nowego typu.

Przy uaktualnianiu z v1 → v2 zasady dotyczące platformy muszą zawierają: 

type sysfs_A; -> (type sysfs_A) (in CIL)
type sysfs; (type sysfs) (in CIL)

W pliku mapowania w wersji 1 (CIL): 

(typeattributeset sysfs_v1 (sysfs sysfs_A))

W pliku mapowania w wersji 2 (CIL): 

(typeattributeset sysfs_v2 (sysfs))
(typeattributeset sysfs_A_v2 (sysfs_A))

W zasadach dostawcy w wersji 1 (CIL): 

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

W zasadach dostawcy w wersji 2 (CIL): 

(typeattribute sysfs_A_v2)
(allow … sysfs_A_v2 …)
(typeattribute sysfs_v2)
(allow … sysfs_v2 …)
Usunięte typy

Ta (rzadka) sytuacja ma miejsce, gdy usunięto typ, co może się zdarzyć, gdy tag bazowy obiekt:

  • Pozostają, ale otrzymują inną etykietę.
  • zostało usunięte przez platformę,

Podczas luzowania zasad typ jest usuwany, a obiekt mu oznaczony etykietą ma inną, istniejącą już etykietę. Reprezentuje to połączenie mapowania atrybutów: kod dostawcy musi nadal mieć dostęp do bazowego przez atrybut, który posiadał. reszta systemu aby uzyskać do niego dostęp za pomocą nowego atrybutu.

Jeśli atrybut, na który został przełączony, jest nowy, ponowne oznaczenie etykietami jak w nowym typie, z tą różnicą, że w przypadku użycia istniejącej etykiety tag dodanie starego atrybutu nowy typ spowodowałoby, że inne obiekty również zostały oznaczone etykietą które mają być nowe. Zasadniczo to się dzieje i jest uznawana za akceptowalny kompromis, aby utrzymać zgodność. 

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Przykładowa wersja 1. Typy zwijania (usuwanie sysfs_A)

Przy uaktualnianiu z v1 → v2 zasady dotyczące platformy muszą zawierają: 

type sysfs; (type sysfs) (in CIL)

W pliku mapowania w wersji 1 (CIL): 

(typeattributeset sysfs_v1 (sysfs))
(type sysfs_A) # in case vendors used the sysfs_A label on objects
(typeattributeset sysfs_A_v1 (sysfs sysfs_A))

W pliku mapowania w wersji 2 (CIL): 

(typeattributeset sysfs_v2 (sysfs))

W zasadach dostawcy w wersji 1 (CIL): 

(typeattribute sysfs_A_v1)
(allow … sysfs_A_v1 …)
(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

W zasadach dostawcy w wersji 2 (CIL): 

(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

Przykładowa wersja 2. Całkowite usunięcie (typ foo)

Przy uaktualnianiu z v1 → v2 zasady dotyczące platformy muszą zawierają: 

# nothing - we got rid of the type

W pliku mapowania w wersji 1 (CIL): 

(type foo) #needed in case vendors used the foo label on objects
(typeattributeset foo_v1 (foo))

W pliku mapowania w wersji 2 (CIL): 

# nothing - get rid of it

W zasadach dostawcy w wersji 1 (CIL): 

(typeattribute foo_v1)
(allow foo …)
(typeattribute sysfs_v1)
(allow sysfs_v1 …)

W zasadach dostawcy w wersji 2 (CIL): 

(typeattribute sysfs_v2)
(allow sysfs_v2 …)
Nowe zajęcia/uprawnienia

Ten scenariusz występuje, gdy uaktualnienie platformy wprowadza nowe komponenty zasad których brak w poprzednich wersjach. Na przykład: gdy Android dodał servicemanager menedżer obiektów, który utworzył dodawanie, znajdowanie i listę demonów dostawców, którzy chcą zarejestrować się w servicemanager potrzebuje uprawnień, które nie zostały i dostępności informacji. W Androidzie 8.0 nowe klasy mogą dodawać tylko zasady platformy uprawnień.

Zezwolenie na wszystkie domeny, które mogły zostać utworzone lub rozszerzone na podstawie zasad dostawcy aby można było bez przeszkód używać nowej klasy, zasady platformy muszą zawierać element reguła podobna do: 

allow {domain -coredomain} *:new_class perm;

Może to nawet wymagać zasady zezwalającej na dostęp do wszystkich interfejsów (polityka publiczna) aby mieć pewność, że obrazy dostawcy uzyskają dostęp. Jeśli powoduje to odrzucenie zasad bezpieczeństwa (tak jak w przypadku zmian menedżera usługi), dostawca przejście na nową wersję może być wymuszone.

Zajęcia i uprawnienia zostały usunięte

Ten scenariusz ma miejsce, gdy zostanie usunięty menedżer obiektów (np. ZygoteConnection menedżera obiektów) i nie powinno powodować problemów. Klasa i uprawnienia menedżera obiektów mogą pozostać zdefiniowane w zasadzie do czasu jego wersja nie jest już używana. W tym celu dodaj definicje do odpowiedniego pliku mapowania.

Dostosowanie dostawcy dla nowe/zmienione etykiety

W razie potrzeby nowe typy dostawców stanowią podstawę opracowywania zasad dotyczących dostawców do opisania nowych procesów, plików binarnych, urządzeń, podsystemów i przechowywanych danych. Jako dlatego konieczne jest umożliwienie tworzenia typów zdefiniowanych przez dostawcę.

Zasada dostawcy jest zawsze najstarsza na urządzeniu, więc nie ma potrzeby automatycznie konwertuje wszystkie typy dostawców na atrybuty w zasadach. Platforma nie polega na niczym oznaczonym w zasadach dostawcy, ponieważ wiedzę na jej temat; platforma udostępni jednak atrybuty i atrybuty publiczne, używane przez niego do interakcji z obiektami z etykietami tego typu (np. domain, sysfs_type itp.). Aby platforma będzie nadal poprawnie korzystać z tych obiektów, atrybutów i typów należy stosować odpowiednie reguły, więc może być konieczne dodanie do domeny konfigurowalne (np. init).

Zmiany atrybutów w Androidzie 9

Urządzenia z Androidem 9 mogą używać podanych niżej atrybutów, ale urządzenia uruchamianych na Androidzie 9.

Atrybuty naruszającego zasady

Android 9 zawiera te atrybuty związane z domeną:

  • data_between_core_and_vendor_violators Atrybut dla wszystkich domen, które naruszają wymaganie dotyczące nieudostępniania plików przez ścieżkę między vendor i coredomains. Platforma procesy dostawcy nie powinny wykorzystywać plików znajdujących się na dysku do komunikacji (niestabilny interfejs ABI). Zalecenia:
    • Kod dostawcy powinien zawierać fragment /data/vendor.
    • System nie powinien używać pola /data/vendor.
  • system_executes_vendor_violators Atrybut dla wszystkich domen systemowych (oprócz init i shell domains) które naruszają wymóg nieużywania plików binarnych dostawców. Realizacja pliki binarne dostawcy mają niestabilny interfejs API. Platforma nie powinna uruchamiać plików binarnych dostawców bezpośrednio. Zalecenia:
    • Takie zależności platformy od plików binarnych dostawcy muszą znajdować się w zawartościach HAL HIDL.

      LUB

    • coredomains, które potrzebują dostępu do plików binarnych dostawcy, powinny mieć została przeniesiona na partycję dostawcy i tym samym przestanie być coredomain.

Niezaufane atrybuty

Niezaufane aplikacje hostujące dowolny kod nie powinny mieć dostępu do HwBinder z wyjątkiem tych uznanych za wystarczająco bezpieczne, aby można było z nich korzystać (zobacz bezpieczne usługi poniżej). Oto 2 główne powody:

  1. Serwery HwBinder nie przeprowadzają uwierzytelniania klienta, ponieważ obecnie HIDL nie ujawnia informacji UID rozmówcy. Nawet jeśli HIDL ujawnia takie dane, wiele osób Usługi HwBinder działają na poziomie niższym niż aplikacje (np. HAL) albo nie może wykorzystywać tożsamości aplikacji na potrzeby autoryzacji. Dlatego też dla bezpieczeństwa domyślnie Założenie jest takie, że każda usługa HwBinder traktuje wszystkich klientów tak samo uprawnione do wykonywania działań oferowanych w ramach usługi.
  2. Serwery HAL (podzbiór usług HwBinder) zawierają kod o wyższej odsetek problemów związanych z bezpieczeństwem niż komponenty system/core i mają dostęp do niższych warstw stosu (a nawet do sprzętu), dzięki czemu to coraz większa szansa na ominięcie modelu zabezpieczeń Androida.

Bezpieczne usługi

Usługi dotyczące bezpieczeństwa obejmują:

  • same_process_hwservice Te usługi (z definicji) działają w przez proces klienta, dzięki czemu masz taki sam dostęp jak jego domena w których działa ten proces.
  • coredomain_hwservice Te usługi nie stwarzają ryzyka w związku z przyczyną nr 2.
  • hal_configstore_ISurfaceFlingerConfigs Ta usługa jest przeznaczone do użytku w dowolnej domenie.
  • hal_graphics_allocator_hwservice Te operacje są również oferowane przez usługę Binder w surfaceflinger, w przypadku których aplikacje są dozwolone. aby uzyskać dostęp.
  • hal_omx_hwservice To jest wersja HwBinder mediacodec Usługa Binder, do której aplikacje mają dostęp.
  • hal_codec2_hwservice To jest nowsza wersja aplikacji hal_omx_hwservice

Przydatne atrybuty

Wszystkie atrybuty hwservices nieuznane za bezpieczne mają atrybut untrusted_app_visible_hwservice Odpowiednie serwery HAL mają atrybut untrusted_app_visible_halserver. Uruchamianie urządzeń z Androidem 9 NIE MOŻE używać żadnej untrusted.

Rekomendacja:

  • Niezaufane aplikacje powinny komunikować się z usługą systemową, która komunikuje się HIDL HAL dostawcy. Na przykład aplikacje mogą komunikować się z binderservicedomain, a potem mediaserver (czyli binderservicedomain) z kolei komunikuje się z hal_graphics_allocator.

    LUB

  • Aplikacje, które potrzebują bezpośredniego dostępu do vendor elementów HAL, powinny mieć zdefiniowaną przez dostawcę domenę sepolicy.

Testy atrybutów plików

Android 9 obejmuje testy czasu kompilacji, które pozwalają sprawdzić, czy wszystkie pliki w określonym formacie lokalizacje mają odpowiednie atrybuty (np. wszystkie pliki w sysfs mają wymagany atrybut sysfs_type).

Polityka publiczna platformy

Polityka dotycząca platformy jest podstawowym elementem dostosowania Androida 8.0 modelu architektury bez utrzymywania jednolitych zasad platformy z wersji 1 i 2. Dostawcy są zobowiązani do pewnego podzbioru zasad platformy, które zawiera przydatne typy i atrybuty oraz reguły tych typów i atrybutów które stają się częścią zasad dla dostawców (tj. vendor_sepolicy.cil).

Typy i reguły są automatycznie tłumaczone w zasadach wygenerowanych przez dostawcę w attribute_vN, tak aby wszystkie typy udostępniane przez platformę są atrybutami wersji (jednak nie ma określonej wersji). Platforma jest odpowiada za mapowanie rodzajów betonu na odpowiednie aby zapewnić, że zasady dostawcy będą nadal działać, a reguły dostępnych dla konkretnej wersji. Kombinacja zasady platformy publicznej i zasady dostawcy spełniają architekturę Androida 8.0 dla modelu, którego celem jest umożliwienie tworzenia niezależnych platform i dostawców.

Mapowanie na łańcuchy atrybutów

W przypadku użycia atrybutów do mapowania na wersje zasad typ jest mapowany na atrybut lub Większa liczba atrybutów, dzięki czemu obiekty z danym typem są dostępne przez odpowiadające ich poprzednim typom.

Utrzymanie celu ukrycia informacji o wersji przed zapisem zasad aby automatycznie generować atrybuty z obsługą wersji i przypisywać je do odpowiednie typy plików. W typowym przypadku statycznych typów treści jest to proste: type_foo wskazuje na type_foo_v1.

W przypadku zmiany etykiety obiektu, takiej jak sysfs → sysfs_A lub mediaserver → audioserver, utworzenie tego mapowania to nie jest proste (i zostało opisane w powyższych przykładach). Administratorzy zasad platformy musi określić sposób tworzenia mapowania w punktach przejściowych obiektów, które wymaga zrozumienia relacji między obiektami a ich przypisanymi i określać, kiedy to nastąpi. Aby zapewnić zgodność wsteczną, zarządzać złożonością po stronie platformy, która jest jedyną partycją, które mogą zwiększyć przychody.

Wzrosty wersji

Dla uproszczenia platforma Androida udostępnia wersję sepolicy, gdy nowy gałąź zwalniająca została wycięta. Jak opisano powyżej, numer wersji jest zawarty w PLATFORM_SEPOLICY_VERSION ma postać MM.nn, gdzie MM odpowiada wartości SDK, a nn to wartość prywatna utrzymywana w /platform/system/sepolicy. Dla np. 19.0 na kijka, 21.0 na Lollipop, 22.0 dla wersji Lollipop-MR1 23.0 for Marshmallow, 24.0 – Nougat, 25.0 – Nougat-MR1, 26.0 – Oreo, 27.0 – Oreo-MR1 oraz 28.0 w przypadku Androida 9. Wzrosty nie zawsze są liczbami całkowitymi. Dla: jeśli na przykład skok na poziomie wersji MR wymaga wprowadzenia niekompatybilnej zmiany system/sepolicy/public, ale nie jest to skok w interfejsie API, to ten sepolicy wersja może być: vN.1. Wersja znajdująca się w wersji deweloperskiej gałąź to 10000.0, którego nie można używać w wysyłce.

Podczas aktualizacji Android może wycofać najstarszą wersję. Do określenia, kiedy należy wycofanie wersji, Android może gromadzić informacje o liczbie urządzeń u dostawcy zasadami, na których działa ta wersja Androida i nadal otrzymujemy główną platformę aktualizacje. Jeżeli liczba jest mniejsza od pewnego progu, ta wersja jest wycofane.

Wpływ na wydajność wiele atrybutów

Jak opisano na stronie https://github.com/SELinuxProject/cil/issues/9, duża liczba atrybutów przypisanych do danego typu powoduje problemy z wydajnością w przypadku pominięcia zasad w pamięci podręcznej.

Potwierdzono, że problem występuje na Androidzie, więc wprowadzone zmiany zostały wprowadzone na Androidzie 8.0 w celu usunięcia atrybutów dodanych do zasady przez kompilatora zasad oraz usuwać nieużywane atrybuty. Te zmiany zostały zakończone na spadki wydajności.

Publiczne zasady publiczne i zasady publiczne dotyczące produktów System_ext

Od Androida 11 partycje system_ext i produkt mogą wyeksportować określone typy publiczne do partycji dostawcy. Polub platformę publicznej, dostawca używa typów i reguł automatycznie przetłumaczonych na atrybuty z obsługą wersji, np. z języka: type na język: type_N, gdzie N to wersja platformy, na której jest zbudowana partycja dostawcy.

Gdy partycje systemowe i partycje produktu są oparte na tej samej wersji platformy N, system kompilacji generuje podstawowe pliki mapowania na system_ext/etc/selinux/mapping/N.cil i product/etc/selinux/mapping/N.cil, które zawierają tożsamość mapowania z type na type_N. Dostawca może: przejdź do folderu type za pomocą atrybutu wersjonowanego type_N.

Jeśli zaktualizowane są tylko partycje system_ext i produkt, powiedz N na N+1 (lub później), podczas gdy dostawca pozostaje na poziomie N, może utracić dostęp do typów partycji systemu system_ext i product. Aby zapobiec uszkodzeniu, System_ext i partycje produktu powinny zawierać pliki mapowania z konkretnych w atrybutach type_N. Każdy partner odpowiada za obsługę plików mapowania, jeśli mają N dostawca z N+1 (lub nowszym) system_ext i partycje produktu.

W tym celu partnerzy powinni:

  1. Skopiuj wygenerowane pliki mapowania podstawowego z urządzenia N system_ext i partycje produktu do drzewa źródłowego.
  2. W razie potrzeby popraw pliki mapowania.
  3. Zainstaluj plików mapowania na N+1 (lub nowsze) system_ext i podziały produktów.

Załóżmy na przykład, że N system_ext ma jeden publiczny typ o nazwie foo_type. Potem system_ext/etc/selinux/mapping/N.cil na N partycji system_ext będzie wyglądać tak: 

(typeattributeset foo_type_N (foo_type))
(expandtypeattribute foo_type_N true)
(typeattribute foo_type_N)

Jeśli do argumentu bar_type dodano element N+1 system_ext, jeśli bar_type powinien być mapowany na foo_type dla Dostawca: N, N.cil, u którego można zaktualizować 

(typeattributeset foo_type_N (foo_type))

  

(typeattributeset foo_type_N (foo_type bar_type))

a potem zainstalowano na partycji systemu N+1 system_ext. N dostawca ma nadal dostęp do: N+1 system_ext: foo_type i bar_type.

Etykiety kontekstów SELinux

W celu uzasadnienia odróżnienia od zasad dotyczących platformy i dostawcy system inaczej kompiluje pliki kontekstowe SELinux, aby oddzielić je od siebie.

Konteksty plików

Android 8.0 wprowadził te zmiany w systemie file_contexts:

  • Aby uniknąć dodatkowej kompilacji na urządzeniu podczas uruchamiania: Element file_contexts nie istnieje już w postaci binarnej. Zamiast tego są zrozumiałe, pliki tekstowe z wyrażeniami regularnymi, takie jak {property, service}_contexts (w starszej wersji niż 7.0).
  • Elementy (file_contexts) są podzielone między 2 pliki:
    • plat_file_contexts
      • Platforma Androida file_context, która nie ma etykiet dla konkretnego urządzenia, oprócz oznaczania elementów /vendor partycja, która musi być dokładnie oznaczona etykietą zapewnić prawidłowe działanie plików sepolicy.
      • Musi znajdować się na partycji system w /system/etc/selinux/plat_file_contexts na urządzeniu oraz zostanie wczytany przez init na początku wraz z parametrem dostawcy file_context.
    • vendor_file_contexts
      • file_context dla konkretnego urządzenia, utworzone przez połączenie file_contexts znaleziono w katalogach wskazywanych przez parametr BOARD_SEPOLICY_DIRS w Boardconfig.mk plików.
      • Musi być zainstalowana w /vendor/etc/selinux/vendor_file_contexts in vendor. Zostanie wczytana przez init o wraz z platformą file_context.

Konteksty usługi

W Androidzie 8.0 element property_contexts jest podzielony na 2 pliki:

  • plat_property_contexts
    • Platforma Androida property_context, która nie ma etykiety dla poszczególnych urządzeń.
    • Musi znajdować się na partycji system w /system/etc/selinux/plat_property_contexts i zostaną wczytane do init na początku wraz z dostawcą property_contexts
  • vendor_property_contexts
    • property_context dla konkretnego urządzenia, utworzone przez połączenie property_contexts znaleziono w katalogach wskazywanych przez parametr BOARD_SEPOLICY_DIRS w: Boardconfig.mk plików.
    • Musi znajdować się na partycji vendor w /vendor/etc/selinux/vendor_property_contexts i być wczytane przez usługę init na początku wraz z platformą property_context

Konteksty usługi

W Androidzie 8.0 obszar service_contexts jest podzielony między: pliki:

  • plat_service_contexts
    • service_context na platformę Android: servicemanager service_context nie ma etykiety dla poszczególnych urządzeń.
    • Musi znajdować się na partycji system w /system/etc/selinux/plat_service_contexts i zostaną wczytane przez servicemanager na początku wraz z dostawcą service_contexts
  • vendor_service_contexts
    • service_context dla konkretnego urządzenia, utworzone przez połączenie service_contexts znaleziono w katalogach wskazywanych przez parametr BOARD_SEPOLICY_DIRS w Boardconfig.mk plików.
    • Musi znajdować się na partycji vendor w /vendor/etc/selinux/vendor_service_contexts i zostaną wczytane przez servicemanager na początku wraz z platformą service_contexts
    • Choć servicemanager szuka tego pliku podczas uruchamiania, dla w pełni zgodnego urządzenia TREBLE, Zasób vendor_service_contexts NIE MOŻE istnieć. Dzieje się tak, ponieważ wszystkie interakcje między vendor a system MUSZĄ zostać przeprowadzony hwservicemanager/hwbinder.
  • plat_hwservice_contexts
    • Platforma Android hwservice_context dla hwservicemanager, który nie ma etykiet dla poszczególnych urządzeń.
    • Musi znajdować się na partycji system w /system/etc/selinux/plat_hwservice_contexts i zostaną wczytane przez hwservicemanager na początku razem z vendor_hwservice_contexts
  • vendor_hwservice_contexts
    • hwservice_context dla konkretnego urządzenia, utworzone przez połączenie hwservice_contexts znaleziono w katalogach wskazywanych przez parametr BOARD_SEPOLICY_DIRS w Boardconfig.mk plików.
    • Musi znajdować się na partycji vendor w /vendor/etc/selinux/vendor_hwservice_contexts i być wczytane przez hwservicemanager na początku wraz z parametrem plat_service_contexts
  • vndservice_contexts
    • service_context dotyczące konkretnego urządzenia dla vndservicemanager – utworzono dzięki połączeniu Znalezione w katalogach wskazywanych przez atrybut vndservice_contexts BOARD_SEPOLICY_DIRS w Boardconfig.mk.
    • Ten plik musi znajdować się na partycji vendor w lokalizacji /vendor/etc/selinux/vndservice_contexts i zostaną wczytane przez vndservicemanager na początku.

Konteksty Seapp

W Androidzie 8.0 element seapp_contexts jest podzielony na 2 pliki:

  • plat_seapp_contexts
    • Platforma Androida seapp_context, która nie ma konkretnego urządzenia zmian.
    • Musi znajdować się na partycji system w /system/etc/selinux/plat_seapp_contexts.
  • vendor_seapp_contexts
    • Utworzono rozszerzenie do platformy seapp_context dostosowane do konkretnego urządzenia Łącząc tag seapp_contexts znaleziony w katalogach wskazuje BOARD_SEPOLICY_DIRS w komponencie Boardconfig.mk plików.
    • Musi znajdować się na partycji vendor w /vendor/etc/selinux/vendor_seapp_contexts

Uprawnienia MAC

W Androidzie 8.0 element mac_permissions.xml jest podzielony na 2 pliki:

  • Peron mac_permissions.xml
    • Platforma Androida mac_permissions.xml, która nie ma zmian na różnych urządzeniach.
    • Musi znajdować się na partycji system w /system/etc/selinux/.
  • Spoza platformy mac_permissions.xml
    • Rozszerzenie na platformę powiązane z konkretnym urządzeniem Urządzenie mac_permissions.xml utworzone na podstawie Znaleziono mac_permissions.xml w katalogach wskazywanych przez atrybut BOARD_SEPOLICY_DIRS w Boardconfig.mk plików.
    • Musi znajdować się na partycji vendor w /vendor/etc/selinux/.