Google is committed to advancing racial equity for Black communities. See how.
Эта страница переведена с помощью Cloud Translation API.
Switch to English

Песочница приложения

Платформа Android использует пользовательскую защиту Linux для идентификации и изоляции ресурсов приложения. Это изолирует приложения друг от друга и защищает приложения и систему от вредоносных приложений. Для этого Android назначает уникальный идентификатор пользователя (UID) каждому приложению Android и запускает его в собственном процессе.

Android использует UID для создания изолированной программной среды приложения на уровне ядра. Ядро обеспечивает безопасность между приложениями и системой на уровне процесса с помощью стандартных средств Linux, таких как идентификаторы пользователей и групп, назначаемые приложениям. По умолчанию приложения не могут взаимодействовать друг с другом и имеют ограниченный доступ к ОС. Если приложение A пытается сделать что-то злонамеренное, например прочитать данные приложения B или набрать номер телефона без разрешения, оно не сможет это сделать, потому что у него нет соответствующих прав пользователя по умолчанию. Песочница проста, поддается аудиту и основана на многолетнем опыте разделения пользователей в стиле UNIX на процессы и права доступа к файлам.

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

Защиты

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

Android полагается на ряд средств защиты для принудительного применения изолированной программной среды приложения. Эти меры были введены с течением времени и значительно укрепили исходную песочницу дискреционного контроля доступа (DAC) на основе UID. Предыдущие выпуски Android включали следующие средства защиты:

  • В Android 5.0 SELinux обеспечивал разделение обязательного контроля доступа (MAC) между системой и приложениями. Однако все сторонние приложения выполнялись в одном контексте SELinux, поэтому изоляция между приложениями в основном обеспечивалась UID DAC.
  • В Android 6.0 песочница SELinux была расширена, чтобы изолировать приложения в пределах границ физических пользователей. Кроме того, Android также установил более безопасные значения по умолчанию для данных приложения: для приложений с targetSdkVersion >= 24 разрешения DAC по умолчанию для targetSdkVersion >= 24 приложения изменены с 751 на 700. Это обеспечило более безопасное значение по умолчанию для данных частного приложения (хотя приложения могут переопределять эти значения по умолчанию) .
  • В Android 8.0 все приложения были настроены для работы с seccomp-bpf который ограничивал системные вызовы, которые разрешалось использовать приложениям, тем самым укрепляя границы приложения / ядра.
  • В Android 9 все непривилегированные приложения с targetSdkVersion >= 28 должны работать в отдельных песочницах SELinux, предоставляя MAC для каждого приложения. Эта защита улучшает разделение приложений, предотвращает переопределение безопасных значений по умолчанию и (что наиболее важно) предотвращает доступ приложений к миру данных.
  • В Android 10 приложения имеют ограниченный необработанный вид файловой системы без прямого доступа к таким путям, как / sdcard / DCIM. Однако приложения сохраняют полный необработанный доступ к своим путям, зависящим от пакета, который возвращается любыми применимыми методами, например Context.getExternalFilesDir () .

Рекомендации по обмену файлами

Установка данных приложения как всемирно доступных - плохая практика безопасности. Доступ предоставляется всем, и невозможно ограничить доступ только предполагаемым получателям. Такая практика привела к утечкам раскрытия информации и запутанным уязвимостям заместителей и является излюбленной целью вредоносных программ, нацеленных на приложения с конфиденциальными данными (например, почтовые клиенты). В Android 9 и выше такой способ обмена файлами явно запрещен для приложений с targetSdkVersion>=28 .

Вместо того, чтобы делать данные приложения общедоступными, при совместном использовании файлов используйте следующие рекомендации:

Разрешение среды выполнения хранилища контролирует доступ к строго типизированным коллекциям через MediaStore . Для доступа к файлам со слабой типизацией, таким как PDF-файлы и класс MediaStore.Downloads , приложения должны использовать намерения, такие как намерение ACTION_OPEN_DOCUMENT .

Чтобы включить поведение Android 10, используйте requestLegacyExternalStorage манифеста requestLegacyExternalStorage и следуйте рекомендациям по разрешению приложений .

  • Значение по умолчанию флага манифеста true для приложений, ориентированных на Android 9 (и ниже).
  • Значение по умолчанию - false для приложений, ориентированных на Android 10. Чтобы временно отказаться от представления фильтрованного хранилища в приложениях, ориентированных на Android 10, установите для флага манифеста значение true .
  • Используя ограниченные разрешения, установщик заносит в белый список приложения, разрешенные для хранения без песочницы. Приложения, не внесенные в белый список, изолированы.