Definiowanie niestandardowych uprawnień aplikacji

W tym dokumencie opisujemy, jak deweloperzy aplikacji mogą korzystać z funkcji zabezpieczeń udostępnianych przez Androida do definiowania własnych uprawnień. Według zdefiniuj niestandardowe uprawnienia, aplikacja będzie mogła udostępniać swoje zasoby i możliwości z innymi aplikacjami. Więcej informacji o uprawnieniach znajdziesz w omówieniu uprawnień.

Tło

Android to oddzielny system operacyjny, w którym każdy aplikacja działa z odrębną tożsamością systemową (identyfikator użytkownika i grupa – Linux) ID). 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ż określać uprawnienia, które są automatycznie udostępniane wszystkim innym aplikacjom podpisanym ten sam certyfikat.

Podpisywanie aplikacji

Wszystkie pliki APK muszą być podpisane certyfikatem. których klucz prywatny jest posiadany przez dewelopera. Certyfikat nie muszą być podpisane 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 protectionLevel aplikacji atrybut dla konkretnego uprawnienia na poziomie podpisu. Następnie system przyzna te uprawnienia aplikacji wysyłającej żądanie, jeśli dowolny sygnatariusz w historii podpisywania, w tym bieżącego podpisującego, pasuje do jednego z skrótów, zadeklarowano z uprawnieniem w atrybucie knownCerts.

Flaga knownSigner umożliwia urządzeniom i aplikacjom przyznawanie uprawnień do podpisu w przypadku: innych aplikacji bez konieczności podpisywania aplikacji w momencie produkcji urządzenia i przesył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ć inne Identyfikator UID – ważne jest, aby każdy pakiet miał w danym przypadku inny identyfikator UID. urządzenia.

Ponieważ egzekwowanie bezpieczeństwa odbywa się na poziomie procesu, kod dwóch pakietów nie może normalnie będą działać w tym samym procesie co użytkownicy systemu Linux.

Wszelkie dane przechowywane przez aplikację są przypisywane do jej użytkownika identyfikatora i nie jest zwykle dostępny dla innych pakietów.

Więcej informacji o modelu zabezpieczeń Androida znajdziesz w artykule Bezpieczeństwo Androida Przegląd.

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 zadeklarowanie wielu pakietów uprawnienia o tej samej nazwie, chyba że wszystkie pakiety są podpisane ten sam certyfikat. 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 poprzedzenie uprawnień nazwą pakietu aplikacji za pomocą polecenia odwrotne nazwy domeny, a po nim ciąg .permission. a potem opis funkcji, którą reprezentuje to uprawnienie. górną część SNAKE_CASE. 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 w przypadku aplikacji, która musi kontrolować, które inne aplikacje mogą ją uruchamiać. może deklarować uprawnienia do tej operacji w taki 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.

android:permissionGroup jest opcjonalny i służy jedynie do ułatwienia systemowi wyświetlania uprawnień po stronie użytkownika. 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 interfejsu uprawnień.

Musisz podać zarówno etykietę, jak i opis uprawnienia. To są zasoby tekstowe, które użytkownik zobaczy, gdy przegląda listę uprawnień. (android:label) lub szczegóły pojedynczego uprawnienia (android:description). Etykieta jest krótka – zawiera kilka słów opisujących kluczowy element funkcje chronione przez to uprawnienie. Opis to zdań opisujących działanie uprawnienia. Nasze konwencja to dwuzdaniowy opis, w którym pierwsze zdanie opisuje uprawnienie i drugie zdanie ostrzega przed użytkownikiem, które mogą pójść nie tak, jeśli aplikacja otrzyma odpowiednie uprawnienia.

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ę zbioru uprawnień – zarówno tych zadeklarowanych w pliku manifestu, <permission> tych zadeklarowanych w innym miejscu. Ma to wpływ tylko na sposób uprawnień pogrupowane podczas prezentacji użytkownikowi. <permission-group> nie określa uprawnień należących do grupy, ale nadaje grupie 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 zdefiniować uprawnienia niestandardowe dla aplikacji i poprosić o niestandardowe uprawnienia od innych aplikacji, definiując elementy <uses-permission>. Warto jednak dokładnie ocenić, czy jest to w przypadku konieczne.

• Jeśli projektujesz pakiet aplikacji, które zapewniają dostęp do funkcji lub tak zaprojektuj aplikacje, aby każde uprawnienie było zdefiniowane tylko raz. Musisz to zrobić, jeśli nie wszystkie aplikacje są podpisane tym samym certyfikat. Nawet jeśli wszystkie aplikacje są podpisane tym samym certyfikatem, najlepiej jest zdefiniować je tylko raz.
• Jeśli funkcja jest dostępna tylko w przypadku aplikacji podpisanych przy użyciu tego samego jako aplikacji dostarczającej treści, możesz uniknąć definiowania uprawnień przez sprawdzanie 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.