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

Вступление

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

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

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

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

Что подразумевается под 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; что могут творить все остальные. Здесь ^[4] об этом можно почитать подробнее.

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

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

...
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 ^[5], который мы уже рассматривали в первой статье. Права доступа определяются отдельно для директорий (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 и прав доступа. Эта функция вызывается во время сборки образа ^[7].

В общем здесь всё должно быть более-менее понятно, за исключением установки флагов прав доступа ^[8] (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 ^[9]:

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

Т.е. вызываются функции setuid и setgid. В этом случае, если данные функции выполнились успешно, то процесс начинает работать от имени owner и owner group данного файла. В нашем примере, данный процесс получает права суперпользователя, т.е. он может делать всё, что ему пожелается :) Подобная анархия не всегда оправдана, поэтому в Linux ввели понятие capabilities ^[10]. Так приложению «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 sun", myuid);
        return 1;
    }
    ...
}

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

Заключение

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

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

Ссылки

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

Автор: zyrik

Источник ^[3]