Вступление
Сегодня я продолжу рассматривать безопасность на уровне немного выше ядра. Во второй части мы рассмотрим, откуда появляются system.img, userdata.img и cache.img, а также как обеспечивается безопасность в Native user space.
Всем кому интересно, добро пожаловать!
Список статей
Здесь собраны ссылки на мои статьи из этой темы:
- Основы безопасности операционной системы Android. Уровень ядра
- Основы безопасности операционной системы Android. Native user space, ч.1
- Основы безопасности операционной системы 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 sun", myuid);
return 1;
}
...
}
Т.е. программа вначале проверяет, от чьего имени запущен вызывающий процесс, используя функцию getuid(). А потом сравнивает эти значения со значениями, которые жестко запрограммированы в систему. В данном случае, только процессы запущенные от имени пользователей «system» и «root» имеют право использовать su.
Заключение
В данной статье мы закончили разбирать, как обеспечивается безопасность на уровне Native user space. В следующих статьях я планирую разобрать, как работают permission (разрешения), но в связи с большой текущей загрузкой не знаю, когда приступлю к их написанию. Как всегда, буду очень рад дополнениям и исправлениям.
P.S. Пригласили подготовить доклад на DevConf@mobi Как вы думаете, будет ли интересен слушателям доклад про безопасность операционной системы Android на конференции, которая больше ориентирована на разработчиков приложений?
Ссылки
- «Embedded Android» by Karim Yaghmour
- «Android Security Underpinnings» by Marko Gargenta
- Linux Users and Groups
- Конфигурация образа
- Suid
- Overview of capabilities
Автор: zyrik
