Определите пользовательское разрешение приложения

В этом документе описывается, как разработчики приложений могут использовать функции безопасности, предоставляемые Android, для определения собственных разрешений. Определяя пользовательские разрешения, приложение может делиться своими ресурсами и возможностями с другими приложениями. Для получения дополнительной информации о разрешениях см. обзор разрешений .

Фон

Android — это операционная система с разделением привилегий, в которой каждое приложение работает с отдельным системным идентификатором (идентификатор пользователя Linux и идентификатор группы). Части системы также разделены на отдельные идентификаторы. Таким образом, Linux изолирует приложения друг от друга и от системы.

Приложения могут предоставлять доступ к своим функциональным возможностям другим приложениям, определяя разрешения, которые другие приложения могут запрашивать. Они также могут определять разрешения, которые автоматически становятся доступными для любых других приложений, подписанных тем же сертификатом.

Подписание приложений

Все APK-файлы должны быть подписаны сертификатом, закрытый ключ которого хранится у разработчика. Сертификат не обязательно должен быть подписан центром сертификации. Для приложений Android допустимо и обычно используются самоподписанные сертификаты. Цель сертификатов в Android — различать авторов приложений. Это позволяет системе предоставлять или запрещать приложениям доступ к разрешениям на уровне подписи , а также разрешать или запрещать приложению запрашивать присвоение ему того же идентификатора Linux, что и другому приложению.

Предоставление прав на подпись после завершения изготовления устройства.

Начиная с Android 12 (уровень API 31), атрибут knownCerts для разрешений на уровне подписи позволяет ссылаться на дайджесты известных сертификатов подписи во время объявления.

Вы можете объявить атрибут knownCerts и использовать флаг knownSigner в атрибуте protectionLevel вашего приложения для определенного разрешения на уровне подписи. Затем система предоставит это разрешение запрашивающему приложению, если любой подписант в цепочке подписей запрашивающего приложения, включая текущего подписанта, соответствует одному из дайджестов, объявленных с разрешением в атрибуте knownCerts .

Флаг knownSigner позволяет устройствам и приложениям предоставлять разрешения на подпись другим приложениям без необходимости подписывать эти приложения во время производства и поставки устройства.

Идентификаторы пользователей и доступ к файлам

При установке Android присваивает каждому пакету уникальный идентификатор пользователя Linux. Этот идентификатор остается неизменным на протяжении всего времени существования пакета на данном устройстве. На другом устройстве один и тот же пакет может иметь другой UID — важно, чтобы каждый пакет имел свой уникальный UID на данном устройстве.

Поскольку обеспечение безопасности происходит на уровне процессов, код любых двух пакетов обычно не может выполняться в одном и том же процессе, так как для этого требуются разные пользователи Linux.

Любые данные, хранящиеся в приложении, получают идентификатор пользователя этого приложения и, как правило, недоступны для других пакетов.

Для получения более подробной информации о модели безопасности Android см. раздел «Обзор безопасности Android» .

Определяйте и контролируйте права доступа.

Чтобы задать собственные разрешения, необходимо сначала объявить их в файле AndroidManifest.xml используя один или несколько элементов <permission> .

Соглашение об именовании

Система не позволяет нескольким пакетам заявлять о разрешении с одинаковым именем, если все пакеты не подписаны одним и тем же сертификатом. Если пакет заявляет о разрешении, система также не позволяет пользователю устанавливать другие пакеты с тем же именем разрешения, если эти пакеты не подписаны тем же сертификатом, что и первый пакет.

Мы рекомендуем добавлять к разрешениям префикс в виде имени пакета приложения, используя обратный доменный стиль именования, за которым следует .permission. и затем описание возможности, которую представляет разрешение, в верхнем регистре (SNAKE_CASE). Например, com.example.myapp.permission.ENGAGE_HYPERSPACE .

Следование этой рекомендации позволяет избежать конфликтов имен и помогает четко определить владельца и назначение пользовательского разрешения.

Пример

Например, приложение, которому необходимо контролировать, какие другие приложения могут запускать одно из его действий, может объявить разрешение на эту операцию следующим образом:

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

Атрибут protectionLevel является обязательным и указывает системе, как информировать пользователей о приложениях, запрашивающих разрешение, или о том, какие приложения могут обладать этим разрешением, как описано в прилагаемой документации.

Атрибут android:permissionGroup является необязательным и используется только для того, чтобы помочь системе отображать пользователю разрешения. В большинстве случаев вы устанавливаете для него стандартную системную группу (указанную в android.Manifest.permission_group ), хотя вы можете определить группу самостоятельно, как описано в следующем разделе. Мы рекомендуем использовать существующую группу, поскольку это упрощает интерфейс управления разрешениями, отображаемый пользователю.

Для разрешения необходимо указать как метку, так и описание. Это строковые ресурсы, которые пользователь может увидеть при просмотре списка разрешений ( android:label ) или подробной информации об отдельном разрешении ( android:description ). Метка короткая: несколько слов, описывающих ключевую функциональность, которую защищает разрешение. Описание состоит из пары предложений, описывающих, что разрешение позволяет делать его обладателю. В нашей практике используется описание из двух предложений, где первое предложение описывает разрешение, а второе предупреждает пользователя о возможных проблемах, которые могут возникнуть, если приложению будет предоставлено это разрешение.

Вот пример метки и описания для разрешения CALL_PHONE :

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

Создайте группу разрешений

Как показано в предыдущем разделе, вы можете использовать атрибут android:permissionGroup , чтобы помочь системе описать разрешения для пользователя. В большинстве случаев вы устанавливаете для него стандартную системную группу (указанную в android.Manifest.permission_group ), но вы также можете определить свою собственную группу с помощью <permission-group> .

Элемент <permission-group> определяет метку для набора разрешений — как тех, которые объявлены в манифесте с помощью элементов <permission> , так и тех, которые объявлены в других местах. Это влияет только на то, как разрешения группируются при отображении пользователю. Элемент <permission-group> не указывает, какие разрешения входят в группу, но задает группе имя.

Вы можете добавить разрешение в группу, присвоив имя группы атрибуту permissionGroup элемента <permission> .

Элемент <permission-tree> объявляет пространство имен для группы разрешений, определенных в коде.

Рекомендации по настройке разрешений

Вы можете задавать пользовательские разрешения для своих приложений и запрашивать пользовательские разрешения у других приложений, определяя элементы <uses-permission> . Однако тщательно оцените, действительно ли это необходимо.

• Если вы разрабатываете набор приложений, которые предоставляют друг другу доступ к своим функциям, постарайтесь спроектировать приложения таким образом, чтобы каждое разрешение определялось только один раз. Это необходимо сделать, если приложения подписаны не одним и тем же сертификатом. Даже если все приложения подписаны одним и тем же сертификатом, рекомендуется определять каждое разрешение только один раз.
• Если функциональность доступна только приложениям, подписанным тем же сертификатом, что и предоставляющее приложение, вы можете избежать определения пользовательских разрешений, используя проверку подписи. Когда одно из ваших приложений отправляет запрос другому приложению, второе приложение может проверить, что оба приложения подписаны одним и тем же сертификатом, прежде чем выполнить запрос.

Если требуется пользовательское разрешение, следует рассмотреть вопрос о том, нужен ли доступ к нему только приложениям, подписанным тем же разработчиком, что и приложение, выполняющее проверку разрешений, — например, при реализации безопасного межпроцессного взаимодействия между двумя приложениями от одного разработчика. В этом случае рекомендуется использовать разрешения на основе подписи . Разрешения на основе подписи прозрачны для пользователя и позволяют избежать подтвержденных пользователем разрешений, которые могут сбивать пользователей с толку.