Реализация безопасности

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

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

Чтобы облегчить внедрение этих лучших практик, где это возможно, команда безопасности Android включает тесты в набор тестов на совместимость Android (CTS) и Android Lint . Мы призываем разработчиков устройств предоставлять тесты, которые могут помочь другим пользователям Android (просмотрите тесты, связанные с безопасностью, по адресу root/cts/tests/tests/security/src/android/security/cts ).

Процесс развития

Используйте следующие рекомендации в своих процессах и среде разработки.

Проверка исходного кода

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

  • Запустите Android Lint для всего кода приложения с помощью Android SDK и исправьте все выявленные проблемы.
  • Собственный код следует анализировать с помощью автоматизированного инструмента, который может обнаружить проблемы с управлением памятью, такие как переполнение буфера и ошибки отклонения на единицу.
  • Система сборки Android поддерживает многие дезинфицирующие средства LLVM, такие как AddressSanitizer и UndefineBehaviorSanitizer, которые можно использовать для этой цели.

Использование автоматического тестирования

Автоматизированное тестирование позволяет обнаружить широкий спектр проблем безопасности, включая несколько проблем, обсуждаемых ниже. Лучшие практики:

  • CTS регулярно обновляется с помощью тестов безопасности; запустите самую последнюю версию CTS, чтобы проверить совместимость.
  • Регулярно запускайте CTS на протяжении всего процесса разработки, чтобы обнаружить проблемы на ранней стадии и сократить время на их исправление. Android использует CTS как часть непрерывной интеграции в нашем автоматизированном процессе сборки, который собирается несколько раз в день.
  • Производители устройств должны автоматизировать тестирование безопасности интерфейсов, включая тестирование с некорректными входными данными (нечеткое тестирование).

Подписание образов системы

Подпись образа системы имеет решающее значение для определения целостности устройства. Лучшие практики:

  • Устройства не должны быть подписаны общеизвестным ключом.
  • Ключи, используемые для подписи устройств, должны управляться в соответствии со стандартными отраслевыми методами работы с конфиденциальными ключами, включая аппаратный модуль безопасности (HSM), который обеспечивает ограниченный, проверяемый доступ.

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

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

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

Публикация приложений

Google Play предоставляет производителям устройств возможность обновлять приложения без выполнения полного обновления системы. Это может ускорить реагирование на проблемы безопасности и предоставление новых функций, а также позволит обеспечить уникальное имя пакета для вашего приложения. Лучшие практики:

  • Загрузите свои приложения в Google Play, чтобы обеспечить автоматическое обновление без необходимости полного беспроводного обновления (OTA). Приложения, которые загружены, но не опубликованы, не могут быть загружены пользователями напрямую, но приложения все равно обновляются. Пользователи, которые ранее установили приложение, могут переустановить его и/или установить на другие устройства.
  • Создайте имя пакета приложения, которое будет четко ассоциироваться с вашей компанией, например, используя товарный знак компании.
  • Приложения, опубликованные производителями устройств, следует загружать в магазин Google Play, чтобы избежать выдачи имени пакета сторонними пользователями. Если производитель устройства устанавливает приложение на устройство, не публикуя его в магазине Play, другой разработчик может загрузить то же приложение, использовать то же имя пакета и изменить метаданные приложения. Когда приложение представляется пользователю, эти несвязанные метаданные могут вызвать путаницу.

Реагирование на инциденты

Внешние стороны должны иметь возможность связываться с производителями устройств по вопросам безопасности конкретных устройств. Мы рекомендуем создать общедоступный адрес электронной почты для управления инцидентами безопасности. Лучшие практики:

  • Создайте адрес security@your-company.com или аналогичный и опубликуйте его.
  • Если вам стало известно о проблеме безопасности, затрагивающей ОС Android или устройства Android от нескольких производителей устройств, вам следует связаться с командой безопасности Android, отправив отчет об ошибке безопасности .

Внедрение продукта

Используйте следующие рекомендации при внедрении продукта.

Изолирование корневых процессов

Корневые процессы являются наиболее частой целью атак повышения привилегий, поэтому уменьшение количества корневых процессов снижает риск повышения привилегий. CTS включает информационный тест, в котором перечислены корневые процессы. Лучшие практики:

  • Устройства должны запускать минимально необходимый код от имени пользователя root. По возможности используйте обычный процесс Android, а не корневой процесс. В ICS Galaxy Nexus всего шесть корневых процессов: vold, inetd, zygote, tf_daemon, ueventd и init. Если процесс должен запускаться на устройстве от имени пользователя root, задокументируйте этот процесс в запросе функции AOSP, чтобы его можно было публично просмотреть.
  • По возможности корневой код должен быть изолирован от ненадежных данных и доступен через IPC. Например, сократите корневую функциональность до небольшой службы, доступной через Binder, и предоставьте службу с разрешением подписи приложению с низкими привилегиями или без них для обработки сетевого трафика.
  • Корневые процессы не должны прослушивать сетевой сокет.
  • Корневые процессы не должны предоставлять среду выполнения общего назначения для приложений (например, виртуальную машину Java).

Изоляция системных приложений

Как правило, предустановленные приложения не должны запускаться с общим системным UID. Однако если приложению необходимо использовать общий UID системы или другой привилегированной службы, приложение не должно экспортировать какие-либо службы, приемники вещания или поставщики контента, к которым могут получить доступ сторонние приложения, установленные пользователями. Лучшие практики:

  • Устройства должны запускать минимально необходимый код как системный. По возможности используйте процесс Android с собственным UID, а не повторно используйте системный UID.
  • По возможности системный код следует изолировать от ненадежных данных и предоставлять IPC только другим доверенным процессам.
  • Системные процессы не должны прослушивать сетевой сокет.

Изолирующие процессы

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

  • Корневые процессы не должны получать доступ к данным в отдельных папках данных приложения, если только не используется документированный метод отладки Android.
  • Корневые процессы не должны получать доступ к памяти приложений, если только не используется документированный метод отладки Android.
  • Устройства не должны включать в себя какие-либо приложения, которые получают доступ к данным или памяти других приложений или процессов.

Защита файлов SUID

Новые программы setuid не должны быть доступны ненадежным программам. Программы Setuid часто являются источником уязвимостей, которые можно использовать для получения root-доступа, поэтому постарайтесь свести к минимуму доступность программы setuid для ненадежных приложений. Лучшие практики:

  • Процессы SUID не должны предоставлять оболочку или бэкдор, который можно использовать для обхода модели безопасности Android.
  • Программы SUID не должны быть доступны для записи никому из пользователей.
  • Программы SUID не должны быть читаемыми или исполняемыми для всех. Создайте группу, ограничьте доступ к двоичному файлу SUID только для членов этой группы и поместите в эту группу все приложения, которые должны иметь возможность выполнять программу SUID.
  • Программы SUID являются распространенным источником рутирования устройств. Чтобы снизить этот риск, программы SUID не должны быть исполняемыми пользователем оболочки.

Верификатор CTS включает информационный тестовый список файлов SUID; некоторые файлы setuid не разрешены в тестах CTS.

Защита розеток для прослушивания

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

  • На устройстве не должно быть прослушивающих портов.
  • Прослушивающие порты должны иметь возможность отключаться без OTA. Это может быть изменение конфигурации сервера или пользовательского устройства.
  • Корневые процессы не должны прослушивать ни один порт.
  • Процессы, принадлежащие системному UID, не должны прослушивать ни один порт.
  • Для локального IPC, использующего сокеты, приложения должны использовать сокет домена UNIX с доступом, ограниченным группой. Создайте файловый дескриптор для IPC и присвойте ему +RW для конкретной группы UNIX. Любые клиентские приложения должны находиться в этой группе UNIX.
  • Некоторые устройства с несколькими процессорами (например, радио/модем, отдельный от процессора приложения) используют сетевые сокеты для связи между процессорами. В таких случаях сетевой сокет, используемый для межпроцессорной связи, должен использовать изолированный сетевой интерфейс для предотвращения доступа неавторизованных приложений на устройстве (то есть использовать iptables для предотвращения доступа других приложений на устройстве).
  • Демоны, обрабатывающие прослушиваемые порты, должны быть устойчивы к искаженным данным. Google может проводить фазз-тестирование порта с использованием неавторизованного клиента и, если возможно, авторизованного клиента. Любые сбои будут зарегистрированы как ошибки с соответствующей серьезностью.

Регистрация данных

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

  • Приложения или системные службы не должны регистрировать данные, предоставленные сторонними приложениями, которые могут содержать конфиденциальную информацию.
  • Приложения не должны регистрировать какую-либо личную информацию (PII) в рамках нормальной работы.

CTS включает тесты, проверяющие наличие потенциально конфиденциальной информации в системных журналах.

Ограничение доступа к каталогу

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

Рекомендуется, чтобы каталоги, созданные системой или пользователями root, не были доступны для записи всем пользователям. Тесты CTS помогают реализовать эту передовую практику, проверяя известные каталоги.

Защита файлов конфигурации

Многие драйверы и службы полагаются на файлы конфигурации и данных, хранящиеся в таких каталогах, как /system/etc и /data . Если эти файлы обрабатываются привилегированным процессом и доступны для записи всем, приложение может использовать уязвимость в процессе, создавая вредоносное содержимое в файле, доступном для записи всем. Лучшие практики:

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

Хранение библиотек собственного кода

Любой код, используемый привилегированными процессами производителя устройства, должен находиться в /vendor или /system ; эти файловые системы монтируются только для чтения при загрузке. Рекомендуется, чтобы библиотеки, используемые системой или другими приложениями с высоким уровнем привилегий, установленными на устройстве, также находились в этих файловых системах. Это может предотвратить уязвимость безопасности, которая может позволить злоумышленнику контролировать код, выполняемый привилегированным процессом.

Ограничение доступа к драйверам устройств

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

Отключение АБР

Мост отладки Android (adb) — это ценный инструмент разработки и отладки, но он предназначен для использования в контролируемых, безопасных средах, и его не следует включать для общего использования. Лучшие практики:

  • ADB должен быть отключен по умолчанию.
  • ADB должен потребовать от пользователя включить его, прежде чем принимать соединения.

Разблокировка загрузчиков

Многие устройства Android поддерживают разблокировку, что позволяет владельцу устройства изменить системный раздел и/или установить собственную операционную систему. Общие случаи использования включают установку стороннего ПЗУ и выполнение разработки на системном уровне на устройстве. Например, владелец устройства Google Nexus может запустить fastboot oem unlock , чтобы начать процесс разблокировки, в результате чего пользователю будет показано следующее сообщение:

Разблокировать загрузчик?

Если вы разблокируете загрузчик, вы сможете установить на это устройство собственное программное обеспечение операционной системы.

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

Чтобы предотвратить несанкционированный доступ к вашим личным данным, разблокировка загрузчика также приведет к удалению всех личных данных с вашего устройства («сброс заводских данных»).

Нажмите кнопки увеличения/уменьшения громкости, чтобы выбрать «Да» или «Нет». Затем нажмите кнопку питания, чтобы продолжить.

Да : разблокировать загрузчик (может привести к аннулированию гарантии)

Нет : не разблокируйте загрузчик и не перезагружайте устройство.


Рекомендуется, чтобы разблокируемые устройства Android перед разблокировкой надежно удаляли все пользовательские данные. Неспособность должным образом удалить все данные при разблокировке может позволить злоумышленнику, находящемуся поблизости, получить несанкционированный доступ к конфиденциальным данным пользователя Android. Чтобы предотвратить раскрытие пользовательских данных, устройство, поддерживающее разблокировку, должно ее правильно реализовать (мы видели множество случаев, когда производители устройств неправильно реализовали разблокировку). Правильно реализованный процесс разблокировки имеет следующие свойства:

  • Когда пользователь подтвердит команду разблокировки, устройство должно начать немедленную очистку данных. Флаг unlocked не должен устанавливаться до завершения безопасного удаления.
  • Если безопасное удаление не может быть завершено, устройство должно оставаться в заблокированном состоянии.
  • Если это поддерживается базовым блочным устройством, следует использовать ioctl(BLKSECDISCARD) или его эквивалент. Для устройств eMMC это означает использование команды Secure Erase или Secure Trim. Для eMMC 4.5 и более поздних версий это означает использование обычного стирания или обрезки с последующей операцией очистки.
  • Если BLKSECDISCARD не поддерживается базовым блочным устройством, вместо него необходимо использовать ioctl(BLKDISCARD) . На устройствах eMMC это обычная операция обрезки.
  • Если BLKDISCARD не поддерживается, допустима перезапись блочных устройств нулями.
  • Конечный пользователь должен иметь возможность потребовать очистки пользовательских данных перед перепрограммированием раздела. Например, на устройствах Nexus это делается с помощью команды fastboot oem lock .
  • Устройство может записывать с помощью efuses или аналогичного механизма, было ли устройство разблокировано и/или повторно заблокировано.

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

Разблокированное устройство можно впоследствии повторно заблокировать с помощью команды fastboot oem lock . Блокировка загрузчика обеспечивает такую ​​же защиту пользовательских данных в новой пользовательской ОС, как и в исходной ОС производителя устройства (например, пользовательские данные будут удалены, если устройство снова разблокируется).