Основы безопасности операционной системы Android. Native user space, ч.2

Вступление

Сегодня я продолжу рассматривать безопасность на уровне немного выше ядра. Во второй части мы рассмотрим, откуда появляются system.img, userdata.img и cache.img, а также как обеспечивается безопасность в Native user space.
Всем кому интересно, добро пожаловать!

Список статей

Здесь собраны ссылки на мои статьи из этой темы:

1. Основы безопасности операционной системы Android. Уровень ядра
2. Основы безопасности операционной системы Android. Native user space, ч.1
3. Основы безопасности операционной системы Android. Native user space, ч.2

Что подразумевается под Native user space

Под Native user space подразумеваются все компоненты пространства пользователя, которые выполняются вне Dalvik Virtual Machine, и которые не являются частью Linux kernel. Native user space — это исполняемые файлы, скомпилированные под определенную архитектуру. К ним относятся исполняемые файлы, которые запускаются из init скрипта автоматически или в случае наступления какого-либо события, toolbox утилиты, а также некоторые исполняемые файлы, которые пользователь может запустить из-под shell.

Начало

Как я уже рассказывал в первой части, в основе Android лежит Linux kernel. Как и во всех Linux системах, в основе безопасности Android лежит access control. Т.е. каждый ресурс (например, файл) содержит мета-информацию о том, кто создал этот файл — owner (владелец) — и к какой основной группе (owner group) принадлежит owner (владелец). Каждый процесс запускается от имени какого-то user (пользователя). У каждого пользователя есть основная группа. Кроме того он может являться членом других групп. Таким образом, если к каждому ресурсу прикрепить информацию (в формате rwxrwxrwx) о том, кто может читать/писать/исполнять ресурс (например, файл), то можно контролировать доступ к этому файлу. Например, файлу можно назначить разрешения: что может делать с этим файлом owner (владелец) этого файла; что могут делать пользователи, которые входят в состав owner group; что могут творить все остальные. Здесь об этом можно почитать подробнее.

Но у Android есть некоторые отличия. Во-первых, изначально Android — это операционная система для телефонов, которые, как известно, относятся к очень личным вещам и которые мы не любим давать в чужие руки. То есть она была задумана как операционная система, у которой только один пользователь. Поэтому было принято решение использовать различных Linux users для обеспечения безопасности (для каждого приложения — отдельный пользователь, как я уже рассказывал в первой статье). Во-вторых, в Android некоторые user (пользователи) и их UID (идентификаторы) были жестко запрограммированы в систему, что вызывает очень много нареканий людей связанных с безопасностью (хотя я, если честно, не очень понимаю, почему критикуется такой подход). Мы уже видели этих пользователей в файле system/core/include/private/android_filesystem_config.h Например, root имеет идентификатор 0, а system — 1000.

Как я уже отмечал, процесс запускается от имени того же пользователя (UID), что и процесс, который запускает этот новый процесс, т.е. UID(calling_process) == UID (called_process). Первый процесс, который запускается в Android — init — запускается от имени root (UID == 0). Таким образом, по-идее, все процессы также должны быть запущены от имени того же пользователи. Так оно, наверное, бы и было. Но, во-первых, процессы, запущенные от имени привилегированного пользователя (а так же те, кто обладает определенными capabilities), могут изменять свой UID на менее привилегированный. А во-вторых, в Android при запуске демонов в init.rc скрипте так же можно указать, с привилегиями какого пользователя и каких групп запускать данный процесс.

... service console /system/bin/sh     class core     console     disabled     user shell     group log ... service servicemanager /system/bin/servicemanager     class core     user system     group system     critical     onrestart restart zygote     onrestart restart media     onrestart restart surfaceflinger     onrestart restart drm ... service media /system/bin/mediaserver     class main     user media     group audio camera inet net_bt net_bt_admin net_bw_acct drmrpc     ioprio rt 4 ...   

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

System, data и cache

Я столько раз анонсировал эту тему, что можно было подумать, что она очень сложная и запутанная. На самом деле, это не так. System.img, userdata.img и cache.img — то, что получается в результате компиляции операционной системы Android. То есть в результате сборки системы получаются эти три файла, которые мы и записываем на наше устройство.

Но самое важно здесь не это. Благодаря тому, что в Android системе user name и UID системных пользователей жестко запрограммированы, уже на этапе компиляции мы можем определить права доступа различных системных пользователей к различным директориям в данных образах. Эти права доступа указаны в файле system/core/include/private/android_filesystem_config.h, который мы уже рассматривали в первой статье. Права доступа определяются отдельно для директорий (android_dirs[]) и отдельно для файлов (android_files[]) следующим образом:

... struct fs_path_config {     unsigned mode;     unsigned uid;     unsigned gid;     uint64_t capabilities;     const char *prefix; };  /* Rules for directories. ** These rules are applied based on "first match", so they ** should start with the most specific path and work their ** way up to the root. */  static const struct fs_path_config android_dirs[] = {     { 00770, AID_SYSTEM, AID_CACHE,  0, "cache" },     { 00771, AID_SYSTEM, AID_SYSTEM, 0, "data/app" },     { 00771, AID_SYSTEM, AID_SYSTEM, 0, "data/app-private" },     { 00771, AID_SYSTEM, AID_SYSTEM, 0, "data/dalvik-cache" },     { 00771, AID_SYSTEM, AID_SYSTEM, 0, "data/data" },     { 00771, AID_SHELL,  AID_SHELL,  0, "data/local/tmp" },     { 00771, AID_SHELL,  AID_SHELL,  0, "data/local" },     { 01771, AID_SYSTEM, AID_MISC,   0, "data/misc" },     { 00770, AID_DHCP,   AID_DHCP,   0, "data/misc/dhcp" },     { 00775, AID_MEDIA_RW, AID_MEDIA_RW, 0, "data/media" },     { 00775, AID_MEDIA_RW, AID_MEDIA_RW, 0, "data/media/Music" },     { 00771, AID_SYSTEM, AID_SYSTEM, 0, "data" },     { 00750, AID_ROOT,   AID_SHELL,  0, "sbin" },     { 00755, AID_ROOT,   AID_SHELL,  0, "system/bin" },     { 00755, AID_ROOT,   AID_SHELL,  0, "system/vendor" },     { 00755, AID_ROOT,   AID_SHELL,  0, "system/xbin" },     { 00755, AID_ROOT,   AID_ROOT,   0, "system/etc/ppp" },     { 00777, AID_ROOT,   AID_ROOT,   0, "sdcard" },     { 00755, AID_ROOT,   AID_ROOT,   0, 0 }, };  /* Rules for files. ** These rules are applied based on "first match", so they ** should start with the most specific path and work their ** way up to the root. Prefixes ending in * denotes wildcard ** and will allow partial matches. */ static const struct fs_path_config android_files[] = {     { 00440, AID_ROOT,      AID_SHELL,     0, "system/etc/init.goldfish.rc" },     { 00550, AID_ROOT,      AID_SHELL,     0, "system/etc/init.goldfish.sh" },     { 00440, AID_ROOT,      AID_SHELL,     0, "system/etc/init.trout.rc" },     { 00550, AID_ROOT,      AID_SHELL,     0, "system/etc/init.ril" },     { 00550, AID_ROOT,      AID_SHELL,     0, "system/etc/init.testmenu" },     { 00550, AID_DHCP,      AID_SHELL,     0, "system/etc/dhcpcd/dhcpcd-run-hooks" },     { 00440, AID_BLUETOOTH, AID_BLUETOOTH, 0, "system/etc/dbus.conf" },     { 00444, AID_RADIO,     AID_AUDIO,     0, "system/etc/AudioPara4.csv" },     { 00555, AID_ROOT,      AID_ROOT,      0, "system/etc/ppp/*" },     { 00555, AID_ROOT,      AID_ROOT,      0, "system/etc/rc.*" },     { 00644, AID_SYSTEM,    AID_SYSTEM,    0, "data/app/*" },     { 00644, AID_MEDIA_RW,  AID_MEDIA_RW,  0, "data/media/*" },     { 00644, AID_SYSTEM,    AID_SYSTEM,    0, "data/app-private/*" },     { 00644, AID_APP,       AID_APP,       0, "data/data/*" },     { 00755, AID_ROOT,      AID_ROOT,      0, "system/bin/ping" },      /* the following file is INTENTIONALLY set-gid and not set-uid.      * Do not change. */     { 02750, AID_ROOT,      AID_INET,      0, "system/bin/netcfg" },      /* the following five files are INTENTIONALLY set-uid, but they      * are NOT included on user builds. */     { 06755, AID_ROOT,      AID_ROOT,      0, "system/xbin/su" },     { 06755, AID_ROOT,      AID_ROOT,      0, "system/xbin/librank" },     { 06755, AID_ROOT,      AID_ROOT,      0, "system/xbin/procrank" },     { 06755, AID_ROOT,      AID_ROOT,      0, "system/xbin/procmem" },     { 06755, AID_ROOT,      AID_ROOT,      0, "system/xbin/tcpdump" },     { 04770, AID_ROOT,      AID_RADIO,     0, "system/bin/pppd-ril" },      /* the following file has enhanced capabilities and IS included in user builds. */     { 00750, AID_ROOT,      AID_SHELL,     (1 << CAP_SETUID) | (1 << CAP_SETGID), "system/bin/run-as" },      { 00755, AID_ROOT,      AID_SHELL,     0, "system/bin/*" },     { 00755, AID_ROOT,      AID_ROOT,      0, "system/lib/valgrind/*" },     { 00755, AID_ROOT,      AID_SHELL,     0, "system/xbin/*" },     { 00755, AID_ROOT,      AID_SHELL,     0, "system/vendor/bin/*" },     { 00750, AID_ROOT,      AID_SHELL,     0, "sbin/*" },     { 00755, AID_ROOT,      AID_ROOT,      0, "bin/*" },     { 00750, AID_ROOT,      AID_SHELL,     0, "init*" },     { 00750, AID_ROOT,      AID_SHELL,     0, "charger*" },     { 00750, AID_ROOT,      AID_SHELL,     0, "sbin/fs_mgr" },     { 00640, AID_ROOT,      AID_SHELL,     0, "fstab.*" },     { 00644, AID_ROOT,      AID_ROOT,      0, 0 }, }; ... 

А функция static inline void fs_config(const char *path, int dir, unsigned *uid, unsigned *gid, unsigned *mode, uint64_t *capabilities), которая определена дальше в этом файле отвечает за выставление owner, owner group, capabilities и прав доступа. Эта функция вызывается во время сборки образа.

В общем здесь всё должно быть более-менее понятно, за исключением установки флагов прав доступа (setuid и setgid) для некоторых файлов (например, для «system/xbin/su» права доступа определены как 06755, где первая 6 означает, что выставлен флаг установки ID пользователя (4) и флаг установки ID группы (2)). Установка этих флагов означает, что пользователь может повысить права запускаемого процесса до уровня owner (владельца) файла или owner group (группы владельца). В случае Android, каждое приложение — это пользователь со своими UID и GID. Таким образом, по умолчанию если вы из своего приложения запускаете какой-нибудь native executable, он исполняется с теми же UID и GID, как и приложение его вызвавшее. Установка данных флагов прав доступа позволяет выполнить native executable с правами владельца. В нашем случае, владелец — AID_ROOT (root). Происходит это следующим обрзазом system/extras/su/su.c:

int main(int argc, char **argv) {     ...     int uid, gid, myuid;     ...     if(setgid(gid) || setuid(uid)) {         ...     } ... } 

Т.е. вызываются функции setuid и setgid. В этом случае, если данные функции выполнились успешно, то процесс начинает работать от имени owner и owner group данного файла. В нашем примере, данный процесс получает права суперпользователя, т.е. он может делать всё, что ему пожелается 🙂 Подобная анархия не всегда оправдана, поэтому в Linux ввели понятие capabilities. Так приложению «run-as» не нужны всё права суперпользователя, ему достаточно иметь возможность только менять свой идентификатор, чтобы запускать приложения от имени различных пользователей. Кстати, capabilities похоже появились недавно — в Android 2.3.x я их не встречал.

Безопасность

В случае привилегированных программ (типа, su) необходимо ограничивать круг приложений, которые могут вызывать эти программы. В противном случае любое приложение может получить права суперпользователя. Поэтому очень часто в такие программы встраивают проверку по UID:

... #include <private/android_filesystem_config.h> ... int main(int argc, char **argv) {     struct passwd *pw;     int uid, gid, myuid;      /* Until we have something better, only root and the shell can use su. */     myuid = getuid();     if (myuid != AID_ROOT && myuid != AID_SHELL) {         fprintf(stderr,"su: uid %d not allowed to su\n", myuid);         return 1;     }     ... } 

Т.е. программа вначале проверяет, от чьего имени запущен вызывающий процесс, используя функцию getuid(). А потом сравнивает эти значения со значениями, которые жестко запрограммированы в систему. В данном случае, только процессы запущенные от имени пользователей «system» и «root» имеют право использовать su.

Заключение

В данной статье мы закончили разбирать, как обеспечивается безопасность на уровне Native user space. В следующих статьях я планирую разобрать, как работают permission (разрешения), но в связи с большой текущей загрузкой не знаю, когда приступлю к их написанию. Как всегда, буду очень рад дополнениям и исправлениям.

P.S. Пригласили подготовить доклад на DevConf@mobi Как вы думаете, будет ли интересен слушателям доклад про безопасность операционной системы Android на конференции, которая больше ориентирована на разработчиков приложений?

Ссылки

1. «Embedded Android» by Karim Yaghmour
2. «Android Security Underpinnings» by Marko Gargenta
3. Linux Users and Groups
4. Конфигурация образа
5. Suid
6. Overview of capabilities