В этом документе описывается, как разработчики приложений могут использовать функции безопасности, предоставляемые 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> . Однако тщательно оцените, необходимо ли это делать.
- Если вы разрабатываете набор приложений, которые раскрывают функциональность друг другу, попробуйте разработать приложения так, чтобы каждое разрешение было определено только один раз. Вы должны сделать это, если не все приложения подписаны одним и тем же сертификатом. Даже если все приложения подписаны одним и тем же сертификатом, лучше всего определять каждое разрешение только один раз.
- Если функциональность доступна только для приложений, подписанных той же подписью, что и предоставляющее приложение, вы можете избежать определения пользовательских разрешений, используя проверки подписи. Когда одно из ваших приложений делает запрос другому вашему приложению, второе приложение может проверить, что оба приложения подписаны одним и тем же сертификатом, прежде чем выполнить запрос.
Если необходимо пользовательское разрешение, подумайте, должны ли к нему иметь доступ только приложения, подписанные тем же разработчиком, что и приложение, выполняющее проверку разрешения, например, при реализации безопасного межпроцессного взаимодействия между двумя приложениями одного разработчика. Если это так, мы рекомендуем использовать разрешения подписи . Разрешения подписи прозрачны для пользователя и позволяют избежать разрешений, подтвержденных пользователем, которые могут сбивать пользователей с толку.
Продолжайте читать о:
-
<uses-permission> - Ссылка на API для тега манифеста, в котором указаны требуемые системные разрешения вашего приложения.
Вас также может заинтересовать:
- Обзор безопасности Android
- Подробное обсуждение модели безопасности платформы Android.
В этом документе описывается, как разработчики приложений могут использовать функции безопасности, предоставляемые 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> . Однако тщательно оцените, необходимо ли это делать.
- Если вы разрабатываете набор приложений, которые раскрывают функциональность друг другу, попробуйте разработать приложения так, чтобы каждое разрешение было определено только один раз. Вы должны сделать это, если не все приложения подписаны одним и тем же сертификатом. Даже если все приложения подписаны одним и тем же сертификатом, лучше всего определять каждое разрешение только один раз.
- Если функциональность доступна только для приложений, подписанных той же подписью, что и предоставляющее приложение, вы можете избежать определения пользовательских разрешений, используя проверки подписи. Когда одно из ваших приложений делает запрос другому вашему приложению, второе приложение может проверить, что оба приложения подписаны одним и тем же сертификатом, прежде чем выполнить запрос.
Если необходимо пользовательское разрешение, подумайте, должны ли к нему иметь доступ только приложения, подписанные тем же разработчиком, что и приложение, выполняющее проверку разрешения, например, при реализации безопасного межпроцессного взаимодействия между двумя приложениями одного разработчика. Если это так, мы рекомендуем использовать разрешения подписи . Разрешения подписи прозрачны для пользователя и позволяют избежать разрешений, подтвержденных пользователем, которые могут сбивать пользователей с толку.
Продолжайте читать о:
-
<uses-permission> - Ссылка на API для тега манифеста, в котором указаны требуемые системные разрешения вашего приложения.
Вас также может заинтересовать:
- Обзор безопасности Android
- Подробное обсуждение модели безопасности платформы Android.