Хабрахабр

Как работает Android, часть 4

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

Статьи серии:

Пакеты

Именно приложения играют ключевую роль в устройстве многих частей системы, именно для гармоничного взаимодействия приложений выстроена модель activity и intent'ов, именно на изоляции приложений основана модель безопасности Android. Как я уже говорил раньше, архитектура Android построена вокруг приложений. И если оркестрированием взаимодействия компонентов приложений занимается activity manager, то за установку, обновление и управление правами приложений отвечает package manager (пакетный менеджер — в shell его можно вызвать командой pm).

Пакеты распространяются в формате APK (Android package) — специальных zip-архивов. Как подсказывает само название «пакетный менеджер», на этом уровне приложения часто называются пакетами. Имена пакетов принято записывать в нотации обратного DNS-имени — например, приложение YouTube использует имя пакета com.google.android.youtube. У каждого пакета есть имя (также известное как application ID), которое уникально идентифицирует это приложение (но не его конкретную версию — наоборот, имена разных версий пакета должны совпадать, иначе они будут считаться отдельными пакетами). Часто имя пакета совпадает с пространством имён, использующимся в его Java-коде, но Android этого не требует (к тому же, APK-файлы приложений обычно включают и сторонние библиотеки, пространство имён которых, естественно, не имеет вообще ничего общего с именами пакетов, которые их используют).

Android проверяет наличие этой подписи при установке приложения, а при обновлении уже установленного приложения дополнительно сравнивает публичные ключи, которыми подписаны старая и новая версия; они должны совпадать, что гарантирует, что новая версия была создана тем же разработчиком, что и старая. Каждый APK при сборке должен быть подписан разработчиком с использованием цифровой подписи. (Если бы этой проверки не было, злоумышленник мог бы создать пакет с таким же именем, как и у существующего приложения, убедить пользователя установить его, «обновляя» приложение, и получить доступ к данным этого приложения.)

Можно и «откатывать» (downgrade) приложения до более старых версий, но при этом по умолчанию Android стирает сохранённые новой версией данные, поскольку старая версия может быть не способна работать с форматами данных, которые использует новая версия. Само обновление пакета представляет собой установку его новой версии вместо старой с сохранением данных и полученных от пользователя разрешений.

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

Это лежит в основе таких «магических» возможностей Android, как динамическая загрузка дополнительных модулей приложения (dynamic feature modules) и Instant Run в Android Studio (автоматическое обновление кода запущенного приложения без его полной переустановки и, во многих случаях, даже без перезапуска). Хотя обычно одному пакету соответствует один файл APK, Android поддерживает пакеты, состоящие из нескольких APK (это называется раздельными APK, или split APK).

Файловая система

Устройство файловой системы — один самых важных и интересных вопросов в архитектуре операционной системы, и устройство файловой системы в Android — не исключение.

Ядро Linux, используемое в Android, в той или иной степени поддерживает большое количество самых разных файловых систем — от используемых в Windows FAT и NTFS и используемых в Darwin печально известной HFS+ и современной APFS — до сетевой 9pfs из Plan 9. Интерес представляет, во-первых, то, какие файловые системы используются, то есть в каком именно формате содержимое файлов сохраняется на условный диск (в случае Android это обычно flash-память и SD-карты) и как обеспечивается поддержка этого формата со стороны ядра системы. Есть и много «родных» для Linux файловых систем — например, Btrfs и семейство ext.

Поэтому нет ничего неожиданного в том, что именно она и используется в Android. Стандартом де-факто для Linux уже долгое время является ext4, используемая по умолчанию большинством популярных дистрибутивов Linux. В некоторых сборках (и некоторыми энтузиастами) также используется F2FS (Flash-Friendly File System), оптимизированная специально для flash-памяти (впрочем, с её преимуществами всё не так однозначно).

Filesystem layout в «обычном Linux» заслуживает более подробного описания (которое можно найти, например, по этой ссылке); я упомяну здесь только несколько наиболее важных директорий: Во-вторых, интерес представляет так называемый filesystem layout — расположение системных и пользовательских папок и файлов в файловой системе.

  • /home хранит домашние папки пользователей; здесь же, в различных скрытых папках (.var.cache.config и других), программы хранят свои настройки, данные и кэш, специфичные для пользователя,
  • /boot хранит ядро Linux и образ initramfs (специальной загрузочной файловой системы),
  • /usr (логичнее было бы назвать /system) хранит основную часть собственно системы, в том числе библиотеки, исполняемые файлы, конфигурационные файлы, а также ресурсы — темы для интерфейса, значки, содержимое системного мануала и т.п.,
  • /etc (логичнее было бы назвать /config) хранит общесистемные настройки,
  • /dev хранит файлы устройств и другие специальные файлы (например, сокет /dev/log),
  • /var хранит изменяемые данные — логи, системный кэш, содержимое баз данных и т.п.

Вот несколько самых важных из его частей: Android использует похожий, но заметно отличающийся filesystem layout.

  • /data хранит изменяемые данные,
  • ядро и образ initramfs хранятся на отдельном разделе (partition) flash-памяти, который не монтируется в основную файловую систему,
  • /system соответствует /usr и хранит систему,
  • /vendor — аналог /system, предназначенный для файлов, специфичных для этой сборки Android, а не входящих в «стандартный» Android,
  • /dev, как и в «обычном Linux», хранит файлы устройств и другие специальные файлы.

Содержимое /system описывает систему и содержит большинство составляющих её файлов. Наиболее интересные из этих директорий — /data и /system. /data также располагается на отдельном разделе и описывает изменяемое состояние конкретного устройства, в том числе пользовательские настройки, установленные приложения и их данные, кэши и т.п. /system располагается на отдельном разделе flash-памяти, который по умолчанию монтируется в режиме read-only; обычно данные на нём изменяются только при обновлении системы. Очистка всех пользовательских данных, так называемый factory reset, при такой схеме заключается просто в очистке содержимого раздела data; нетронутая система остаётся установлена в разделе system.

# mount | grep /system
/dev/block/mmcblk0p14 on /system type ext4 (ro,seclabel,relatime,data=ordered)
# mount | grep /data
/dev/block/mmcblk0p24 on /data type ext4 (rw,seclabel,nosuid,nodev,noatime,noauto_da_alloc,data=writeback)

Каждому предустановленному приложению при создании сборки Android выделяется папка с именем вида /system/app/Terminal, а для устанавливаемых пользователем приложений при установке создаются папки, имена которых начинаются с их имени пакета. Приложения — а именно, их APK, файлы odex (скомпилированный ahead-of-time Java-код) и ELF-библиотеки — устанавливаются в /system/app (для приложений, поставляемых с системой) или в /data/app (для установленных пользователем приложений). Например, приложение YouTube сохраняется в папку с названием вроде /data/app/com.google.android.youtube-bkJAtUtbTuzvAioW-LEStg==/.

Про этот суффикс

Использование такого суффикса не позволяет другим приложениям «угадать» путь к приложению, о существовании которого им знать не следует. Суффикс в названии папок приложений — 16 случайных байт, закодированных в Base64. В принципе, список установленных на устройстве приложений и путей к ним не является секретом — его можно получить через стандартные API — но в некоторых случаях (а именно, для Instant apps) на доступ к этим данным накладываются ограничения.

Каждый раз при обновлении приложения новая APK устанавливается в папку с новым суффиксом, после чего старая папка удаляется. Этот суффикс служит и другой цели. 0 Oreo в этом и состояло назначение суффиксов, и вместо случайных байт поочерёдно использовались -1 и -2 (например, /data/app/com.google.android.youtube-2 для YouTube). До версии 8.

Полный путь к папке приложения в /system/app или /data/app можно получить с помощью стандартного API или команды pm path org.example.packagename, которая выводит пути всех APK-файлов приложения.

# pm path com.android.egg
package:/system/app/EasterEgg/EasterEgg.apk

Тем не менее, поддерживается обновление предустановленных приложений — при этом для новой версии создаётся папка в /data/app, а поставляемая с системой версия остаётся в /system/app. Поскольку предустановленные приложения хранятся в разделе system (содержимое которого, напомню, изменяется только при обновлении системы), их невозможно удалить (вместо этого Android предоставляет возможность их «отключить»). В этом случае у пользователя появляется возможность «удалить обновления» такого приложения, вернувшись к версии из /system/app.

Например, сторонним приложениям не получить разрешения DELETE_PACKAGES, которое позволяет удалять другие приложения, REBOOT, позволяющего перезапустить систему, и READ_FRAME_BUFFER, позволяющего получить прямой доступ к содержимому экрана. Другая особенность предустановленных приложений — они могут получать специальные «системные» разрешения. Эти разрешения имеют уровень защиты signature, то есть приложение, пытающееся получить доступ к ним, должно быть подписаны тем же ключом, что и приложение или сервис, которые их реализуют — в этом случае, поскольку эти разрешения реализованы системой, ключом, которым подписана сама сборка Android.

Доступ к этой папке есть только у самого приложения — то есть только у UID, под которым запускается это приложение (если приложение использует несколько UID, или несколько приложений используют общий UID, всё может быть сложнее). Для хранения изменяемых данных каждому приложению выделяется папка в /data/data (например, /data/data/com.google.android.youtube для YouTube). В этой папке приложения сохраняют настройки, кэш (в подпапках shared_prefs и cache соответственно) и любые другие нужные им данные:

# ls /data/data/com.google.android.youtube/
cache code_cache databases files lib no_backup shared_prefs
# cat /data/data/com.google.android.youtube/shared_prefs/youtube.xml
<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map> <string name="user_account">username@gmail.com</string> <boolean name="h264_main_profile_supported7.1.2" value="true" /> <int name="last_manual_video_quality_selection_max" value="-2" /> <...>
</map>

При удалении приложения вся папка этого приложения полностью удаляется, и приложение не оставляет за собой следов. Система знает о существовании папки cache и может очищать её самостоятельно при нехватке места. Альтернативно, и то, и другое пользователь может явно сделать в настройках:

Это выделяемое каждому приложению хранилище данных называется внутренним хранилищем (internal storage).

По сути, внешнее хранилище играет роль домашней папки пользователя — именно там располагаются такие папки, как Documents, Download, Music и Pictures, именно внешнее хранилище открывают файловые менеджеры в качестве папки по умолчанию, именно к содержимому внешнего хранилища Android позволяет получить доступ компьютеру при подключении по кабелю. Кроме того, в Android есть и другой тип хранилища — так называемое внешнее хранилище (external storage — это название отражает изначальную задумку о том, что внешнее хранилище должно было располагаться на вставляемой в телефон внешней SD-карте).

# ls /sdcard
Alarms Download Podcasts
Android Movies Ringtones
Books Music Subtitles
DCIM Notifications bluetooth
Documents Pictures

Как я уже упоминал в прошлой статье, это разрешение стоит запрашивать таким приложениям, как файловый менеджер; а большинству остальных приложений лучше использовать intent с действием ACTION_GET_CONTENT, предоставляя пользователю возможность самому выбрать нужный файл в системном файловом менеджере. В отличие от внутреннего хранилища, разделённого на папки отдельных приложений, внешнее хранилище представляет собой «общую зону»: к нему есть полный доступ у любого приложения, получившего соответствующее разрешение от пользователя.

Для этого Android выделяет приложениям во внешнем хранилище папки с названиями вида Android/data/com.google.android.youtube. Многие приложения предпочитают сохранять и некоторые из своих внутренних файлов, имеющие большой размер (например, кэш загруженных изображений и аудиофайлов) во внешнем хранилище. При удалении приложения система удалит и его специальную папку во внешнем хранилище; но файлы, созданные приложениями во внешнем хранилище вне их специальной папки считаются принадлежащими пользователю и остаются на месте после удаления создавшего их приложения. Самому приложению для доступа к такой папке не требуется разрешение на доступ ко всему внешнему хранилищу (поскольку в качестве владельца этой папки устанавливается его UID), но к этой папке может получить доступ любое другое приложение, имеющее такое разрешение, поэтому её, действительно, стоит использовать только для хранения публичных и некритичных данных.

С тех пор многие условия изменились; в современных телефонах часто нет слота для SD-карты, зато устанавливается огромное по мобильным меркам количество встроенной памяти (например, в Samsung Galaxy Note 9 её может быть до 512 гигабайт). Как я упомянул выше, исходно предполагалось, что внешнее хранилище действительно будет располагаться на внешней SD-карте, поскольку в то время объём SD-карт значительно превышал объём встраиваемой в телефоны памяти (в том же самом HTC Dream её было лишь 256 мегабайта, из которых на раздел data выделялось порядка 90 мегабайт).

Настоящий путь, по которому располагается внешнее хранилище в файловой системе, имеет форму /data/media/0 (для каждого пользователя устройства создаётся отдельное внешнее хранилище, и число в пути соответствует номеру пользователя). Поэтому в современном Android практически всегда и внутреннее, и внешнее хранилища располагаются во встроенной памяти. В целях совместимости до внешнего хранилища также можно добраться по путям /sdcard, /mnt/sdcard, /storage/self/primary, /storage/emulated/0, нескольким путям, начинающимся с /mnt/runtime/, и некоторым другим.

Вставленную в Android-устройство SD-карту можно использовать как обычный внешний диск (не превращая её во внутреннее или внешнее хранилище системы) — сохранять на неё файлы, открывать хранящиеся на ней файлы, использовать её для перенесения файлов на другие устройства и т.п. С другой стороны, у многих устройств всё-таки есть слот для SD-карты. При этом система переформатирует SD-карту и шифрует её содержимое — хранящиеся на ней данные невозможно прочесть, подключив её к другому устройству. Кроме того, Android позволяет «заимствовать» SD-карту и разместить внутреннее и внешнее хранилище на ней (это называется заимствованным хранилищем — adopted storage).

Подробнее почитать про всё это можно, например, вот в этом посте и в официальной документации для разработчиков приложений и для создателей сборок Android.

Загрузка

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

И если серьёзные многопользовательские сервера можно и нужно охранять от неавторизованного физического доступа, к персональным компьютерам — а тем более мобильным устройствам — такой подход просто неприменим. Именно на защиту от программных атак ориентирована модель ограничения прав пользователей в Unix (и основанная на ней технология app sandbox в Android); само по себе ограничение прав в Unix никак не защищает систему от пользователя, пробравшегося в серверную и получившего физический доступ к компьютеру.

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

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

Именно с этими двумя направлениями защиты связана модель безопасной загрузки в Android.

Verified Boot

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

Bootloader — это относительно простая программа, в задачи которой (при загрузке в обыкновенном режиме) входят: Прежде всего, Android-устройства, в отличие от «десктопных» компьютеров, обычно не позволяют пользователю (или злоумышленнику) произвести загрузку со внешнего носителя; вместо этого сразу запускается установленный на устройстве bootloader (загрузчик).

  • инициализация и настройка Trusted Execution Environment (например, ARM TrustZone),
  • нахождение разделов встроенной памяти, в которых хранятся образы ядра Linux и initramfs,
  • проверка их целостности и неприкосновенности (integrity) — в противном случае загрузка прерывается с сообщением об ошибке — путём верификации цифровой подписи производителя,
  • загрузка ядра и initramfs в память и передача управления ядру.

Flashing, unlocking, fastboot и recovery

Кроме того, bootloader поддерживает дополнительную функциональность для обновления и переустановки системы.

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

Для этого bootloader способен загружаться в ещё один специальный режим, который называют fastboot mode (или иногда просто bootloader mode), поскольку обычно для общения между компьютером и bootloader'ом в этом режиме используется протокол fastboot (и соответствующий ему инструмент fastboot из Android SDK со стороны компьютера). Это делается путём использования второй «фичи» bootloader'а, направленной на обновление и переустановку системы — поддержки перезаписи (flashing) содержимого и структуры разделов по командам с подсоединённого по кабелю компьютера.

В основном это касается устройств, выпускаемых компанией Samsung, где специальная реализация bootloader'a (Loke) общается с компьютером по собственному проприетарному протоколу (Odin). Некоторые реализации bootloader'а используют другие протоколы. Для работы с Odin со стороны компьютера можно использовать либо реализацию от самих Samsung (которая тоже называется Odin), либо свободную реализацию под названием Heimdall.

Конкретные детали зависят от реализации bootloader'а (то есть различаются в зависимости от производителя устройства), но во многих случаях установка recovery и сборок Android, подписанных ключом производителя устройства, просто работает без дополнительных сложностей:

$ fastboot flash recovery recovery.img
$ fastboot flash boot boot.img
$ fastboot flash system system.img

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

Именно так обычно устанавливаются такие популярные дистрибутивы Android, как LineageOS (бывший CyanogenMod), Paranoid Android, AOKP, OmniROM и другие. Кроме того, многие устройства поддерживают разблокировку bootloader'а (unlocking the bootloader, также известную как OEM unlock) — отключение проверки bootloader'ом подписи системы и recovery, что позволяет устанавливать произвольные сборки того и другого (у части производителей это аннулирует гарантию).

Если систему переустанавливает сам пользователь, а не злоумышленник, после переустановки он может восстановить свои данные из бэкапа (например, из облачного бэкапа на серверах Google или из бэкапа на внешнем носителе), если злоумышленник — он получит работающую систему, но не сможет украсть данные владельца устройства. Поскольку разблокировка bootloader'а всё-таки позволяет загрузить на устройстве собственную версию системы, в целях безопасности при разблокировке все пользовательские данные (с раздела data) принудительно удаляются.

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

Для разблокировки bootloader'а может также потребоваться дополнительно разрешить её из настроек системы:

Она содержит тач-интерфейс и множество продвинутых «фич», в том числе возможность устанавливать части системы из сборок в виде zip-архивов, встроенную поддержку бэкапов и даже полноценный эмулятор терминала с виртуальной клавиатурой: Популярная сторонняя recovery, которую устанавливают большинство «флешаголиков» (flashaholics) — TWRP (Team Win Recovery Project).

Шифрование диска

Этот механизм основан на встроенной в ext4 поддержке шифрования, реализованной в ядре Linux (fscrypt), и позволяет системе зашифровывать различные части файловой системы различными ключами. Современные версии Android используют пофайловое шифрование данных (file-based encryption).

Это означает, что при загрузке система должна попросить пользователя ввести свой пароль, чтобы вычислить с его помощью ключ для расшифровки данных. По умолчанию система шифрует большинство данных пользователя, расположенных на разделе data, с помощью ключа, который создаётся на основе пароля пользователя и не сохраняется на диск (credential encrypted storage). Именно поэтому первый раз после включения устройства пользователя встречает требование ввести полный пароль или графический ключ, а не просто пройти аутентификацию, приложив палец к сканеру отпечатков.

Файлы, зашифрованные таким образом, система может расшифровать до того, как пользователь введёт пароль. В дополнение к credential encrypted storage в Android также используется device encrypted storage — шифрование ключом на основе данных, которые хранятся на устройстве (в том числе в Trusted Execution Environment). Например, Direct Boot позволяет будильнику срабатывать и до первого ввода пароля, что особенно полезно, если устройство непредвиденно перезагружается ночью из-за временного отключения питания или сбоя системы. Это лежит в основе функции, известной как Direct Boot: система способна загружаться в некоторое работоспособное состояние и без ввода пароля; при этом приложения могут явно попросить систему сохранить (наименее приватную) часть своих данных в device encrypted storage, что позволяет им начинать выполнять свои базовые функции, не дожидаясь полной разблокировки устройства.

Root

Напомню, что root — это специально выделенный Unix-пользователь, которому — за несколькими интересными исключениями — разрешён полный доступ ко всему в системе, и на которого не распространяются никакие ограничения прав. Так называемый root-доступ — это возможность выполнять код от имени «пользователя root» (UID 0, также известного как суперпользователь).

В отличие от более закрытых операционных систем, пользователи которых называют разрушение наложенных на них ограничений буквально «побегом из тюрьмы», в Android прямо «из коробки», без необходимости получать root-доступ и устанавливать специальные сторонние «твики», есть возможность: Как и большинство других современных операционных систем, Android спроектирован с расчётом на то, что обыкновенному пользователю ни для чего не требуется использовать root-доступ.

  • устанавливать произвольные приложения — как из множества существующих магазинов приложений, так и произвольные APK из любых источников,
  • выбирать приложения по умолчанию: веб-браузер, email-клиент, камеру, файловый менеджер, лончер, приложение для звонков, приложение для СМС, приложение для контактов и так далее (это работает за счёт красивой системы activity и intent'ов, которую я описал в прошлой статье),
  • устанавливать и использовать пакеты значков (icon packs),
  • получать прямой доступ к файловой системе, хранить в ней произвольные файлы,
  • подключать устройство к компьютеру (или даже к другому Android-устройству) и напрямую передавать между ними файлы по кабелю,
  • и даже, во многих дистрибутивах Android, настраивать цвета и шрифты системной темы.

В то же время использование root-доступа неизбежно сопряжено со многими проблемами с безопасностью (подробнее о них ниже), поэтому в большинстве случаев Android не позволяет пользователю работать от имени root. Итак, для обыкновенных задач, с которыми может столкнуться простой пользователь, root-доступ не нужен. Приложения, в том числе эмуляторы терминалов, выполняются от имени своих ограниченных Unix-пользователей; а shell, который запускается при использовании команды adb shell, работает от имени специально для этого предназначенного Unix-пользователя shell.

Тем не менее, бывает, что root доступен пользователю:

  • Во-первых, root-доступ обычно разрешён на сборках Android для эмуляторов — поставляемых вместе с Android Studio виртуальных машин на базе QEMU, которые изображают реальные устройства и обычно используются разработчиками для отладки и тестирования приложений.
  • Во-вторых, root-доступ включён по умолчанию во многих сторонних дистрибутивах Android (pre-rooted ROMs).
  • В-третьих, при разблокированном bootloader'е root-доступ на любой сборке Android можно включить напрямую, просто установив исполняемый файл, реализующий команду su, через bootloader.
  • Ну и наконец, в-четвёртых, на старых версиях системы, содержащих известные уязвимости, часто можно получить root-доступ, проэксплуатировав их (обычно для получения root-доступа эксплуатируются сразу несколько уязвимостей в разных слоях и компонентах системы). Например, если система не обновлялась с первой половины 2016 года, для получения root-доступа можно воспользоваться получившей широкую известность уязвимостью Dirty Cow.

Конечно, root-доступ полезен для отладки и исследования работы системы. Зачем это может быть нужно? Можно принудительно подменять код и ресурсы приложений — например, можно удалить из приложения рекламу или разблокировать его платную или скрытую функциональность. Кроме того, обладая root-доступом, можно неограниченно настраивать систему, изменяя её темы, поведение и многие другие аспекты. Можно устанавливать, изменять и удалять произвольные файлы, в том числе в разделе system (хотя это почти наверняка плохая идея).

С более философской точки зрения, root-доступ позволяет пользователю полностью контролировать своё устройство и свою систему — вместо того, чтобы устройство и разработчики ПО контролировали пользователя.

Проблемы root-доступа

With great power comes great responsibility.

Другими словами, с root-доступом связано большое количество проблем в области безопасности и стабильности системы. С большими возможностями приходит и большая ответственность, и совсем не всегда эту ответственность можно доверить пользователю и приложениям.

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

Тем более нельзя доверять приложениям root-доступ, надеясь, что они буду использовать его только во благо. Как я уже говорил во второй статье серии, в отличие от традиционной модели доверия программам в классическом Unix, Android рассчитан на то, что пользователь не может доверять сторонним приложениям — поэтому их и помещают в песочницу. Фактически, root-доступ разрушает аккуратно выстроенную модель безопасности Android, снимая с приложений все ограничения и открывая им права на доступ ко всему в системе.

Например, разработчики приложения, содержащего платную функциональность, естественно, не захотят, чтобы проверку совершения покупки можно было отключить. С другой стороны, и приложения не могут доверять устройству, на котором подключен root-доступ, поскольку на таком устройстве в его работу имеют возможность непредусмотренными способами вмешиваться пользователь и остальные приложения. Многие приложения, работающие с особенно ценными данными — например, Google Pay (бывший Android Pay) — явно отказываются работать на устройствах с root-доступом, считая их недостаточно безопасными.

Аналогично, онлайн-игры вроде популярной Pokémon GO тоже отказываются работать на root-ованных устройствах, опасаясь, что игрок сможет с лёгкостью нарушить правила игры.

Google Play и root-доступ

А поскольку Play Store — наиболее известный и популярный (как среди разработчиков приложений, так и среди пользователей) магазин приложений для Android, большинство производителей предпочитают предустанавливать его на свои устройства. Google разрешает производителям предустанавливать Google Play Store и Google Play Services только на устройства, где root-доступ отключён, тем самым делая Android более привлекательной платформой для разработчиков, которые, естественно, предпочитают вкладывать ресурсы в разработку под платформы, не позволяющие пользователям с лёгкостью вмешиваться в работу их приложений. Именно поэтому root-доступ по умолчанию отключён на большинстве популярных Android-устройств. (Есть и исключения — например, Amazon использует собственный дистрибутив Android под названием Fire OS для своих устройств — Echo, Fire TV, Fire Phone, Kindle Fire Tablet — и не предустанавливает никаких приложений от Google).

Несмотря на ограничение для производителей, Google разрешает пользователям сборок, в которых разрешён root-доступ, самостоятельно устанавливать Google Play (обычно это делается путём установки готовых пакетов от проекта Open GApps); при этом Google требует, чтобы после установки пользователь вручную зарегистрировал устройство на специально предназначенной для этого странице регистрации.

To be certified, a device must pass Android compatibility tests. Device manufacturers work with Google to certify that Android devices with Google apps installed are secure and will run apps correctly. As a result, your device is uncertified. If you are unable to add a Google Account on your Android device, your Android device software might not have passed Android compatibility tests, or the device manufacturer has not submitted the results to Google to seek approval. This means that your device might not be secure.

If you are a User wanting to use custom ROMs on your device, please register your device by submitting your Google Services Framework Android ID below.

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

В дополнение к собственно авторизации это служит подтверждением того, что пользователь доверяет этой программе и согласен предоставить ей возможность воспользоваться root-доступом. В «обычном» Linux, как и в других Unix-системах, для получения root-доступа (с помощью команд sudo и su) пользователю требуется ввести пароль (или свой, или пароль Unix-пользователя root, в зависимости от настройки системы и конкретной команды) или авторизоваться другим способом (например, с помощью отпечатка пальца).

Многие сторонние реализации su позволяют любому приложению получать права суперпользователя, что, как я объяснил выше, очень плохо в плане безопасности. Стандартная версия команды su из Android Open Source Project не запрашивает подтверждения пользователя явно, но она доступна только Unix-пользователю shell (и самому root), что полностью отрезает приложениям возможность получать root-права.

При попытке приложения вызвать su они запрашивают подтверждение у пользователя, который может разрешить или запретить приложению получить root-доступ. В качестве компромисса многими пользователями используются специальные программы, которые управляют доступом к su. Несколько лет назад была популярна одна из таких программ, SuperSU; в последнее время её вытеснил новый открытый проект под названием Magisk.

Magisk

В сочетании с Magisk Hide — возможностью не просто не давать некоторым приложениям root-доступ, а полностью прятать от них сам факт наличия root-доступа и установки Magisk в системе — это позволяет устройству по-прежнему получать обновления системы от производителя и использовать приложения вроде того же Google Pay, которые отказываются работать на root-ованных системах. Основная особенность Magisk — возможность проведения широкого класса модификаций системы, в том числе связанных с изменением файлов, расположенных в папке /system, на самом деле не изменяя сам раздел system (это называют словом systemless-ly), путём использования нескольких продвинутых «фич» Linux. Magisk Hide способен обходить даже такие достаточно продвинутые технологии обнаружения root-а, как SafetyNet от Google.

Приложения, которым пользователь доверил root-доступ, по-прежнему могут решить вмешаться в работу системы и украсть деньги пользователя через Google Pay. Хотя это действительно невероятно круто, нужно осознавать, что возможность использовать приложения вроде Google Pay на root-ованных устройствах несмотря на встроенные в них проверки — это не решение связанных с root-доступом проблем с безопасностью. Проблемы с безопасностью остаются, нам лишь удаётся закрыть на них глаза.

В таком виде доступны, например, известный root-фреймворк Xposed и ViPER, набор продвинутых драйверов и настроек для воспроизведения звука. Magisk поддерживает systemless-ную установку готовых системных «твиков» в виде Magisk Modules, специальных пакетов для установки с использованием Magisk.

SoC, драйвера и фрагментация

Системы на кристалле

Аппаратное обеспечение традиционных настольных и серверных компьютеров построено вокруг материнской платы, на которую устанавливаются такие важнейшие компоненты «харда», как центральный процессор и оперативная память, и к которой затем подключаются дополнительные платы — например, графическая и сетевая — содержащие остальные компоненты (соответственно, графический процессор и Wi-Fi адаптер).

Система на кристалле представляет собой набор компонентов компьютера — центральный процессор, блок оперативной памяти, порты ввода-вывода, графический процессор, LTE-, Bluetooth- и Wi-Fi-модемы и т.п. В отличие от такой схемы, в большинстве Android-устройств используются так называемые системы на кристалле (system on a chip, SoC). Такой подход позволяет не только уменьшить физический размер устройства, чтобы оно поместилось в кармане, и повысить его производительность за счёт большей локальности и лучшей интеграции между компонентами, но и значительно снизить его энергопотребление и тепловыделение, что особенно актуально для мобильных устройств, питающихся от встроенной батарейки и не имеющих систем активного охлаждения. — полностью реализованных и интегрированных в рамках одного микрочипа.

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

О драйверах

Как и в традиционных системах, основанных на отдельных платах, каждый компонент системы на кристалле — от камеры до LTE-модема — требует для работы использования специальных драйверов. Другой — гораздо более важный именно в контексте Android — недостаток SoC заключается в связанных с ними сложностях с драйверами. Но в отличие от традиционных систем, эти драйвера обычно разрабатываются производителями систем на кристалле и специфичны для их конкретных моделей; кроме того, исходные коды таких драйверов обычно не раскрываются, да и бинарные сборки в свободный доступ производителями выкладываются совсем не всегда.

Так и получается, что сборка Android, предустановленная на устройстве производителем, содержит все нужные для этого устройства драйвера, а напрямую использовать сборку для одного устройства на другом невозможно. Вместо этого производитель SoC (например, Qualcomm) отдаёт готовую сборку драйверов производителям Android-устройств (например, Sony или LG), которые включают её в свою сборку Android, основанную на коде из Android Open Source Project.

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

Фрагментация

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

Но оно приносит и две гораздо более серьёзные проблемы. Конечно, медленное обновление экосистемы означает, что не все пользователи получают небольшие обновления интерфейса и другие видимые пользователю улучшения, которые приносят новые версии Android.

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

В теории, несмотря на внутренние различия в драйверах и пользовательском интерфейсе разных версий и сборок Android, используемые разработчиками приложений API — Android Framework, OpenGL/Vulkan и другие — должны быть переносимы и работать одинаково. Во-вторых, фрагментация отрицательно сказывается на разработчиках приложений под Android — страдает так называемый developer experience (DX, по аналогии с user experience/UX). На практике это, конечно, не всегда так, и разработчикам приходится тестировать и обеспечивать работу своих приложений на множестве версий и сборок Android — на разных устройствах, разных версиях системы, сторонних дистрибутивах и так далее.

Don't Stop Thinking About Tomorrow

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

Android вполне можно установить и на обычный «десктопный» компьютер (подойдут, например, сборки от проектов Android-x86 и RemixOS). Кроме того, совсем не все устройства, где используется Android, построены на основе SoC. Аналогичного подхода — запуска специальной сборки Android в контейнере — придерживается проект Anbox, позволяющий использовать Android-приложения на «обыкновенных» Linux-системах. Специальная сборка Android встроена в ChromeOS, что позволяет Chromebook'ам запускать Android-приложения наряду с Linux-приложениями и веб-приложениями. (Напомню, что Android-приложения так легко переносятся на x86-архитектуры, не требуя перекомпиляции, благодаря использованию виртуальной машины Java, о чём я рассказывал во второй статье серии.)

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

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

В 2017 году Google анонсировали Project Treble — новую, ещё более модульную (по сравнению с уже существующим HAL, hardware abstraction layer) архитектуру взаимодействия драйверов (и остального софта, специфичного для конкретного устройства) с остальными частями системы. И такое решение уже существует. Treble позволяет устанавливать основную систему и драйвера, специфичные для устройства, на разные разделы файловой системы, и обновлять — или как угодно изменять — систему отдельно от установленных драйверов.

Благодаря Treble устройства от семи разных компаний (Sony, Nokia, OnePlus, Oppo, Xiaomi, Essential и Vivo — а не только от самих Google) смогли участвовать в бета-программе Android Pie. Treble в корне меняет ситуацию с медленным выпуском обновлений и плохой переносимостью сборок. Одну и ту же сборку Android — один и тот же бинарный файл без перекомпиляции или каких-либо изменений — теперь можно запускать на любом устройстве, поддерживающем Treble, несмотря на то, что они могут быть основаны на совершенно разных SoC. Treble позволил Essential выпустить обновление до Android Pie для своего Essential Phone прямо в день выхода Android Pie.

Java принесла возможность «write once, run everywhere» для высокоуровневого кода — в том числе и возможность запускать Android-приложения на компьютерах с практически любой архитектурой процессора. Влияние Treble действительно сложно переоценить. Теперь дело за производителями, которым нужно конвертировать свои драйвера в формат, совместимый с Treble. Treble — аналогичный прорыв, позволяющий использовать однажды написанную и скомпилированную сборку Android на устройствах с совершенно разными SoC. Можно надеяться, что через несколько лет проблемы с обновлениями Android-устройств исчезнут окончательно.

В следующей статье я планирую рассказать о низкоуровневом userspace Android: о процессе init, о Zygote, Binder, сервисах и props.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть