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

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

На этой странице представлены рекомендации по обеспечению безопасности, основанные на нашем опыте, которые дополняют документацию Designing for Security , которую мы предоставили разработчикам, и включают сведения, уникальные для создания или установки программного обеспечения системного уровня на устройствах.

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

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

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

Просмотр исходного кода

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

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

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

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

• 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 . Блокировка загрузчика обеспечивает такую ​​же защиту пользовательских данных в новой пользовательской ОС, какая была доступна в исходной ОС производителя устройства (например, пользовательские данные будут стерты, если устройство снова будет разблокировано).