Definiowanie niestandardowych uprawnień aplikacji

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

W tym dokumencie opisaliśmy, jak deweloperzy aplikacji mogą korzystać z funkcji bezpieczeństwa Androida, aby definiować własne uprawnienia. Definiując niestandardowe uprawnienia, aplikacja może udostępniać swoje zasoby i możliwości innym aplikacjom. Więcej informacji o uprawnieniach znajdziesz w omówieniu uprawnień.

Tło

Android to system operacyjny z oddzielonymi uprawnieniami, w którym każda aplikacja działa z osobną tożsamością systemową (identyfikator użytkownika i grupy w systemie Linux). Części systemu są też rozdzielone na osobne tożsamości. W ten sposób Linux izoluje aplikacje od siebie nawzajem i od systemu.

Aplikacje mogą udostępniać swoje funkcje innym aplikacjom, definiując uprawnienia o dostęp do których mogą poprosić inne aplikacje. Mogą też definiować uprawnienia, które są automatycznie udostępniane wszystkim innym aplikacjom podpisanym tym samym certyfikatem.

Podpisywanie aplikacji

Wszystkie pliki APK muszą być podpisane certyfikatem, którego klucz prywatny jest przechowywany przez dewelopera. Certyfikat nie musi być podpisany przez urząd certyfikacji. Są dozwolone. jest typowa dla aplikacji na Androida, które używają samodzielnie podpisanych certyfikatów. Cel certyfikatów w Androidzie służą do rozróżniania autorów aplikacji. Dzięki temu system przyznaje aplikacjom dostęp na poziomie podpisu lub go odrzuca uprawnienia i przyznać lub odrzucić prośbę o przyznanie aplikacji tą samą tożsamością w systemie Linux co inna aplikacja.

Przyznaj uprawnienia do podpisu po zakończeniu produkcji urządzenia

Począwszy od Androida 12 (poziom interfejsu API 31) Atrybut knownCerts dla uprawnienia na poziomie podpisu umożliwiają odwoływanie się do skrótów znanych podpisywania certyfikaty w deklaracji obecnie się znajdujesz.

Możesz zadeklarować atrybut knownCerts i użyć flagi knownSigner w atrybutach protectionLevel aplikacji w przypadku konkretnego uprawnienia na poziomie podpisu. Następnie system przyznaje to uprawnienie aplikacji, która je zażądała, jeśli podpisujący w jej linii podpisywania (w tym bieżący podpisujący) odpowiada jednemu z skrótów zadeklarowanych w przypisie knownCerts.

Flaga knownSigner umożliwia urządzeniom i aplikacjom przyznawanie uprawnień do podpisywania innym aplikacjom bez konieczności podpisywania aplikacji w momencie ich produkcji i wysyłki.

Identyfikatory użytkowników i dostęp do plików

Podczas instalacji Android nadaje każdemu pakietowi inny identyfikator użytkownika systemu Linux. tożsamość pozostaje stała przez cały okres życia przesyłki na danym urządzenia. Na innym urządzeniu ten sam pakiet może mieć inny identyfikator UID – ważne jest, aby każdy pakiet miał unikalny identyfikator UID na danym urządzeniu.

Wymuszanie zabezpieczeń odbywa się na poziomie procesu, więc kod dowolnych 2 pakietów nie może być zwykle wykonywany w tym samym procesie, ponieważ muszą być one wykonywane jako różne konta użytkowników systemu Linux.

Wszystkie dane przechowywane przez aplikację są przypisywane do identyfikatora użytkownika tej aplikacji i zwykle nie są dostępne dla innych pakietów.

Więcej informacji o modelu bezpieczeństwa Androida znajdziesz w artykule Omówienie zabezpieczeń Androida.

Definiowanie i egzekwowanie uprawnień

Aby egzekwować własne uprawnienia, musisz najpierw zadeklarować je w AndroidManifest.xml używa co najmniej jednej funkcji <permission>.

Konwencja nazewnictwa

System nie zezwala na to, aby wiele pakietów deklarowało uprawnienie o tej samej nazwie, chyba że wszystkie pakiety są podpisane tym samym certyfikatem. Jeśli pakiet deklaruje uprawnienia, system także ich nie deklaruje nie zezwalają użytkownikowi na instalowanie innych pakietów z tą samą nazwą uprawnienia, chyba że te pakiety są podpisane tym samym certyfikatem co pierwszy pakiet.

Zalecamy przedrostek uprawnień nazwą pakietu aplikacji za pomocą polecenia odwrotne nazwy domeny, z dopiskiem .permission. a potem opis funkcji, którą reprezentuje to uprawnienie. górną część SNAKE_CASE. Na przykład: com.example.myapp.permission.ENGAGE_HYPERSPACE.

Przestrzeganie tego zalecenia pozwala uniknąć konfliktów w nazwach i ułatwia jednoznaczną określić właściciela i przeznaczenie uprawnień niestandardowych.

Przykład

Na przykład aplikacja, która musi kontrolować, które inne aplikacje mogą uruchamiać jedną z jej aktywności, może zadeklarować uprawnienie do tej operacji w ten sposób:

<manifest
  xmlns:android="http://schemas.android.com/apk/res/android"
  package="com.example.myapp" >
    
    <permission
      android:name="com.example.myapp.permission.DEADLY_ACTIVITY"
      android:label="@string/permlab_deadlyActivity"
      android:description="@string/permdesc_deadlyActivity"
      android:permissionGroup="android.permission-group.COST_MONEY"
      android:protectionLevel="dangerous" />
    ...
</manifest>

Atrybut protectionLevel jest wymagany i informuje system, jak informować użytkowników o aplikacjach wymagających uprawnień lub o tym, mają uprawnienia zgodnie z opisem w linkowanej dokumentacji.

Atrybut android:permissionGroup jest opcjonalny i służy tylko do wyświetlania uprawnień użytkownikowi. W większości przypadków jest to system standardowy grupa (z listy android.Manifest.permission_group), chociaż możesz samodzielnie zdefiniować grupę zgodnie z opisem w następnej sekcji. Zalecamy użycie istniejącej grupy, ponieważ upraszcza to wyświetlany użytkownikowi interfejs uprawnień.

Musisz podać zarówno etykietę, jak i opis uprawnienia. To zasoby tekstowe, które użytkownik może zobaczyć, gdy wyświetla listę uprawnień (android:label) lub szczegóły dotyczące pojedynczego uprawnienia (android:description). Etykieta jest krótka: to kilka słów opisujących główną funkcję, którą chroni dane uprawnienia. Opis składa się z kilku zdań opisujących, co uprawnienie pozwala zrobić. Zgodnie z naszą konwencją opis składa się z 2 zdań: pierwsze opisuje uprawnienie, a drugie ostrzega użytkownika przed tym, co może pójść nie tak, jeśli aplikacja uzyska uprawnienie.

Oto przykład etykiety i opisu CALL_PHONE uprawnienie:

<string name="permlab_callPhone">directly call phone numbers</string>
<string name="permdesc_callPhone">Allows the app to call non-emergency
phone numbers without your intervention. Malicious apps may cause unexpected
calls on your phone bill.</string>

Utwórz grupę uprawnień

Jak pokazano w poprzedniej sekcji, Atrybut android:permissionGroup, który ma pomóc systemowi opisać uprawnienia użytkownika. W większości przypadków służy do ustawienia standardowego grupa systemowa (lista w android.Manifest.permission_group), ale możesz też zdefiniować własną grupę, <permission-group>

Element <permission-group> definiuje etykietę dla zestawu uprawnień – zarówno tych zadeklarowanych w pliku manifestu za pomocą elementów <permission>, jak i tych zadeklarowanych w innym miejscu. Ma to wpływ tylko na sposób grupowania uprawnień podczas wyświetlania ich użytkownikowi. Element <permission-group> nie określa uprawnień należących do grupy, ale nadaje jej nazwę.

Możesz przyznać uprawnienie w grupie, przypisując nazwę grupy do <permission> elementu permissionGroup .

<permission-tree> deklaruje przestrzeń nazw dla grupy uprawnień zdefiniowanych w w kodzie.

Rekomendacje dotyczące uprawnień niestandardowych

Możesz definiować niestandardowe uprawnienia dla swoich aplikacji i prosić o niestandardowe uprawnienia z innych aplikacji, definiując elementy <uses-permission>. Warto jednak dokładnie ocenić, czy jest to w przypadku konieczne.

• Jeśli opracowujesz pakiet aplikacji, które udostępniają sobie nawzajem funkcje, postaraj się zaprojektować je tak, aby każde uprawnienie było zdefiniowane tylko raz. Musisz to zrobić, jeśli nie wszystkie aplikacje są podpisane tym samym certyfikatem. Nawet jeśli wszystkie aplikacje są podpisane tym samym certyfikatem, zalecamy zdefiniowanie każdego uprawnienia tylko raz.
• Jeśli funkcja jest dostępna tylko dla aplikacji podpisanych tym samym podpisem co aplikacja udostępniająca, możesz uniknąć definiowania niestandardowych uprawnień, korzystając z sprawdzeń podpisu. Gdy któraś z aplikacji wyśle żądanie druga z Twoich aplikacji, druga aplikacja może sprawdzić, czy obie są podpisane o tym samym certyfikacie przed spełnieniem żądania.

Jeśli potrzebne jest uprawnienie niestandardowe, sprawdź, czy tylko aplikacje są podpisane przez tego samego programistę, co aplikacja przeprowadzająca sprawdzanie uprawnień musi np. podczas wdrażania bezpiecznej komunikacji międzyprocesowej. między dwiema aplikacjami tego samego programisty. Jeśli tak, zalecamy użycie uprawnienia do podpisu. Uprawnienia do podpisu są przejrzyste dla użytkownika i nie powinny być potwierdzone przez użytkownika uprawnień, co może być mylące dla użytkowników.