Lista dozwolonych uprawnień uprzywilejowanych

Uprzywilejowane aplikacje są aplikacje systemowe, które są zlokalizowane w priv-app katalogu na jednej z partycji systemu graficznych. Partycje używane w wydaniach Androida to

  • Android 8.1 i niższe - /system
  • Android 9 i wyższe - /system, /product, /vendor

W całej tej stronie /etc/permissions/priv-app postanawia partition /etc/permissions/priv-app .

Historycznie rzecz biorąc, producenci urządzeń miał niewielką kontrolę nad którym podpis | uprzywilejowane uprawnienia mogłyby zostać przyznany uprzywilejowanych aplikacji. Począwszy od Androida 8.0, producenci muszą wyraźnie przyznają uprzywilejowane uprawnienia w konfiguracji systemu plików XML w /etc/permissions katalogu. Począwszy od Androida 9, implementatorzy muszą jawnie przyznać lub odmówić wszystkich uprzywilejowanych uprawnień, w przeciwnym razie urządzenie nie uruchomi się.

privapp-permissions.xml plik może jedynie udzielić lub odmówić uprawnienia dla uprzywilejowanych aplikacji na tej samej partycji. Na przykład, jeśli aplikacja na /product partycji żąda uprzywilejowanych uprawnień, wniosek może zostać udzielone lub odrzucone przez tylko privapp-permissions.xml pliku, który znajduje się również na /product .

Dodawanie list dozwolonych

Allowlists zgodę na aplikacje mogą być wymienione w jednym pliku XML lub w wielu plikach XML znajdujących się w frameworks/base/etc/permissions katalogu, co następuje:

  • /etc/permissions/privapp-permissions- OEM_NAME .xml
  • /etc/permissions/privapp-permissions- DEVICE_NAME .xml

Nie ma ścisłych zasad porządkowania treści. Realizatorzy urządzenia można określić strukturę zawartości, o ile wszystkie aplikacje z /system/priv-app są allowlisted. Na przykład Google ma jedną listę dozwolonych dla wszystkich uprzywilejowanych aplikacji opracowanych przez Google i zaleca następującą organizację:

  • Uprawnienia dla aplikacji, które są już zawarte w drzewie (AOSP) Android Open Source Project są wymienione w /etc/permissions/privapp-permissions-platform.xml .
  • Uprawnienia dla aplikacji Google są wymienione w /etc/permissions/privapp-permissions-google.xml .
  • W przypadku innych aplikacji, plików Zastosowanie postaci: /etc/permissions/privapp-permissions- DEVICE_NAME .xml .

Generowanie list dozwolonych

Aby automatycznie wygenerować allowlist dla wszystkich aplikacji dostępnych na obrazie systemu, należy użyć narzędzia wiersza polecenia AOSP w development/tools/privapp_permissions/privapp_permissions.py . Aby wygenerować początkową wersję dla danego urządzenia privapp-permissions.xml :

  1. Budowanie obrazu systemu:
        . build/envsetup.sh
        lunch PRODUCT_NAME
        make -j
  2. Uruchom privapp_permissions.py skrypt do generowania privapp-permissions.xml plik z listą wszystkich podpis | uprzywilejowane uprawnienia wymagane do allowlisted:
    development/tools/privapp_permissions/privapp_permissions.py
    To narzędzie drukuje zawartość XML, który może być stosowany jako pojedynczy plik lub podzielone na wiele plików w /etc/permissions ścieżce katalogu. Jeżeli urządzenie zawiera już allowlists w na /etc/permissions katalogów, narzędzie wyświetla tylko różnic (takich jak brakującego podpisu | uprzywilejowanych uprawnień trzeba dodać do allowlist). Jest to również przydatne do celów audytu: po dodaniu nowej wersji aplikacji narzędzie wykrywa dodatkowe wymagane uprawnienia.
  3. Skopiować wygenerowane odpowiednie pliki do /etc/permissions katalogu, gdzie system odczytuje pliki podczas uruchamiania.

Dostosowywanie list dozwolonych

AOSP obejmuje implementację listy dozwolonych, którą można dostosować w razie potrzeby. Uprawnienia dla aplikacji wchodzących w AOSP już allowlisted w /etc/permissions/privapp-permissions-platform.xml .

Domyślnie privapp_permissions.py skrypt generuje wyjście, które automatycznie przyznaje żądane przez uprzywilejowanej wniosku o pozwolenie. Jeśli istnieją uprawnienia, których należy odmówić, edytuj kod XML, aby użyć tagu „odmowa uprawnień” zamiast tagu „uprawnienia”. Przykład:

<!-- This XML file declares which signature|privileged permissions to grant to
privileged apps that come with the platform -->

    <permissions>
    <privapp-permissions package="com.android.backupconfirm">
    <permission name="android.permission.BACKUP"/>
    <permission name="android.permission.CRYPT_KEEPER"/>
    </privapp-permissions>

    <privapp-permissions package="com.android.cellbroadcastreceiver">

    <!-- Don't allow the application to interact across users -->

    <deny-permission name="android.permission.INTERACT_ACROSS_USERS"/>
    <permission name="android.permission.MANAGE_USERS"/>
    <permission name="android.permission.MODIFY_PHONE_STATE"/>
    <permission name="android.permission.READ_PRIVILEGED_PHONE_STATE"/>
    <permission name="android.permission.RECEIVE_EMERGENCY_BROADCAST"/>
    </privapp-permissions>
    ...

Znajdowanie brakujących uprawnień

Aby znaleźć brakujące uprawnienia podczas uruchamiania nowego urządzenia, włącz tryb dziennika przejściowego:

ro.control_privapp_permissions=log

Naruszenia są zgłaszane w pliku dziennika, ale nieuprzywilejowane uprawnienia są nadal przyznawane. Dzięki temu urządzenie jest w stanie roboczym, jednocześnie wyświetlając listę naruszeń. Oto format komunikatu o błędzie:

PackageManager: Privileged permission {PERMISSION_NAME} for package {PACKAGE_NAME} - not in privapp-permissions allowlist

Wszystkie naruszenia należy rozwiązać, dodając brakujące uprawnienia do odpowiednich list dozwolonych.

  • W Androidzie 8.0 i niższe, dotknięte aplikacje nie są przyznawane brakujące uprawnienia, nawet jeśli są one w priv-app ścieżce.
  • Na Androidzie 9 i wyżej, naruszenia (uprzywilejowanych uprawnień) oznacza urządzenie nie uruchamia się. Należy jawnie zezwolić lub zablokować wszystkie uprzywilejowane uprawnienia

Egzekwowanie list dozwolonych

Po allowlists są na miejscu, umożliwi egzekwowanie wykonania przez ustawienie kompilacji własności ro.control_privapp_permissions=enforce .