В прошлой статье мы рассмотрели простые решения изоляции, которые сможет использовать даже самый ленивый и неискушенный пользователь. Но как работают эти системы? Какие технологии лежат в их основе и почему Docker, не открыв ничего нового, стал настолько популярен? Попробуем ответить на эти вопросы, а заодно на коленке соберем свою собственную песочницу на базе ядра Linux.

 

Вместо введения

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

Один из ранних примеров песочницы — это системный вызов chroot и одноименная команда. Он появился еще в Version 7 оригинального UNIX в 1979 году, а в 1982-м перекочевал в BSD. Chroot выполняет очень простую вещь: он позволяет сделать так, чтобы корневым каталогом для приложения стал не настоящий корень, а указанный пользователем (или программистом) каталог. В результате приложение оказывается как бы замкнуто внутри этого каталога, не зная, что существует что-то за его пределами.

На примере размещение приложения в chroot выглядит приблизительно так. Для начала создаем «корневой» каталог для приложения и копируем его туда:

$ sudo mkdir ~/sandbox
$ sudo mkdir ~/sandbox/bin
$ sudo cp `which ls` ~/sandbox/bin

Далее выясняем, от каких библиотек зависит приложение, и тоже копируем их в chroot. Это необходимо сделать, потому что после запуска в chroot оно просто не сможет увидеть и, как следствие, загрузить библиотеки основной системы.

$ ldd `which ls`
linux-vdso.so.1 (0x00007ffe51efd000)
libcap.so.2 => /usr/lib/libcap.so.2 (0x00007f19da03c000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f19d9c9b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f19da240000)
$ sudo mkdir -p ~/sandbox/usr/lib
$ sudo mkdir ~/sandbox/lib64
$ sudo cp /usr/lib/libcap.so.2 /usr/lib/libc.so.6 ~/sandbox/usr/lib
$ sudo cp /lib64/ld-linux-x86-64.so.2 ~/sandbox/lib64

Библиотека linux-vdso.so.1 — виртуальная и входит в состав libc, поэтому ее мы пропускаем. Теперь, когда все готово, можно запустить наш bin/ls в chroot:

$ sudo chroot ~/sandbox /bin/ls -l /
total 12
drwxr-xr-x 2 0 0 4096 Jul 12 07:20 bin
drwxr-xr-x 2 0 0 4096 Jul 12 07:35 lib64
drwxr-xr-x 3 0 0 4096 Jul 12 07:34 usr

Как видишь, хотя мы попросили команду ls отобразить содержимое корневого каталога, нам показали содержимое ~/sandbox. Бинарник ls замкнут в этом каталоге, и файлов основной системы для него как бы не существует. Казалось бы, вот она, песочница для запуска сервисов и небезопасного софта! Да, долгое время chroot использовали для этих целей, но есть одна тонкость. Для ls виртуальной стала только файловая система (а если точнее — файловая иерархия), тогда как все остальные сущности ядра (список процессов, сетевой стек, разделяемая память) остались общими с основной системой.

Если ты создашь внутри chroot каталог proc, смонтируешь к нему файловую систему procfs, а затем закинешь в chroot и запустишь бинарник ps, то обнаружишь, что из chroot видно все процессы основной системы. IP-адрес и правила брандмауэра также останутся неизменными. Приложения, использующие разделяемую память и другие механизмы IPC, смогут общаться с процессами хост-системы. А процесс, работающий в chroot с правами root, сможет легко покинуть песочницу.

 

Укрепляем песочницу

Для решения этих проблем во FreeBSD еще в 2000-м году появился механизм jail, прозванный «chroot на стероидах». Он позволил отделить процессы основной системы от процессов внутри chroot/jail, ограничить доступ к сети и переменным ядра, назначить каждому виртуальному окружению собственный hostname, а начиная с FreeBSD 9.0 — ограничить использование ресурсов.

Разработчики Linux пошли несколько другим путем и реализовали концепцию «пространств имен» (namespaces). Это уже более комплексный и универсальный механизм, позволяющий выполнить над ресурсами/сущностями ядра (список процессов, разделяемая память, сетевой стек) примерно ту же операцию, что chroot выполняет над файловой иерархией, то есть отрезать выбранное приложение от основной системы. Существует множество разных типов пространств имен:

  • PID — пространство имен процессов, ограничивает область видимости только процессами, которые были порождены самим приложением, и закрывает доступ ко всем остальным процессам системы;
  • Mount — позволяет монтировать файловые системы так, чтобы они были видны только самому приложению и его потомкам;
  • IPC — отрезает процессы, использующие разделяемую память, семафоры и очереди сообщений, от процессов хост-системы;
  • Network — создает отдельный сетевой стек для приложения и его потомков, с собственными IP-адресами, правилами брандмауэра, таблицами маршрутизации, правилами QoS и так далее;
  • UTS — позволяет привязать к приложению и потомкам собственное доменное имя;
  • User — создает собственную таблицу пользователей и групп.

Красота пространств имен в том, что их очень просто применить. Достаточно запустить приложение под управлением команды unshare, передав ей несколько флагов. Попробуй для примера выполнить следующую команду:

$ sudo unshare -p --fork --mount-proc /usr/bin/ps -aux

Несмотря на то что мы прямо попросили ps показать все системные процессы (флаги -aux), в списке процессов оказывается только сам ps. Такое происходит потому, что мы запустили ps в собственном пространстве имен процессов (флаг -p и флаги --fork и --mount-proc, чтобы смонтировать /proc по новой уже после применения пространства имен). Можешь заменить /usr/bin/ps на /usr/bin/top, чтобы убедиться, что top тоже не может «заглянуть» за пределы пространства имен.

Утилита top, запущенная в пространстве имен процессов
Утилита top, запущенная в пространстве имен процессов

Команда unshare позволяет запускать приложение и в любых других пространствах имен, поэтому, объединив ее с командой chroot, мы можем создать по-настоящему изолированную песочницу:

$ sudo unshare -piumU --fork --mount-proc chroot ~/sandbox /bin/ls -l /

Эта команда создаст все перечисленные выше пространства имен (кроме сетевого) и запустит /bin/ls внутри них. Это уже почти настоящее виртуальное окружение с собственным точками монтирования, юзерами, списком процессов. Единственное, чего не хватает, — это выделенный сетевой стек (сетевое пространство имен). Его мы создадим с помощью другой команды — ip. Но для начала нам нужен виртуальный сетевой мост, который будет служить выходом виртуального окружения в сеть.

Создаем сетевой мост и подключаем его к физическому сетевому интерфейсу eth0 (у тебя его имя, скорее всего, будет другим, запусти ifconfig, чтобы узнать точно):

$ sudo brctl addbr br0
$ sudo brctl addif br0 eth0
$ sudo dhcpcd br0

Далее создаем новое сетевое пространство имен (назовем его sandbox), а также пару сцепленных друг с другом виртуальных сетевых интерфейсов (veth), один из которых (eth1) пробросим в это пространство имен:

$ sudo ip netns add sandbox
$ sudo link add veth1 type veth peer name eth1
$ sudo link set eth1 netns sandbox

Подключаем виртуальный сетевой интерфейс к мосту и запускаем dhcpcd для получения IP-адреса:

$ sudo brctl addif br0 veth1
$ sudo ip link set veth1 up
$ sudo ip netns exec dhcpcd eth1

В качестве последнего штриха добавляем в виртуальное окружение адрес DNS-сервера (это будет гугловский 8.8.8.8):

$ sudo mkdir ~/sandbox/etc
$ sudo echo 'nameserver 8.8.8.8' > ~/sandbox/etc/resolv.conf

Осталось только запустить наше виртуальное окружение в полученном пространстве имен:

$ sudo ip netns exec unshare -piumU --fork --mount-proc chroot ~/sandbox /bin/ls -l /
 

Воздвигаем стены

Для примера с /bin/ls это неважно, но настоящее виртуальное окружение также должно ограничивать доступные приложению ресурсы, будь то процессор, память или пропускная способность дисковой подсистемы. Для этих целей в ядре Linux есть механизм cgroups (control groups), позволяющий объединить процессы в группы и привязать к ним так называемые контроллеры, которые будут ограничивать те или иные ресурсы. Всего существует около десятка различных контроллеров, наиболее полезные из них:

  • blkio — устанавливает лимиты на скорость ввода-вывода;
  • cpu — позволяет ограничить использование процессора;
  • cpuset — привязывает группу процессов к определенному процессорному ядру;
  • devices — открывает/закрывает доступ к определенным устройствам;
  • freezer — позволяет замораживать процессы в группе;
  • memory — устанавливает лимиты на использование оперативной памяти.

Мы для простоты будем использовать только два контроллера: cpu и memory. Для начала создадим группу контроллеров:

$ sudo cgcreate -g cpu,memory:/sandbox

Далее установим лимиты. С памятью все просто, указываем прямым текстом 128 Мбайт:

$ sudo cgset -r memory.limit_in_bytes=128M sandbox

С процессором дела обстоят несколько сложнее. Здесь необходимо указывать период процессорного времени в миллисекундах и квоту, выделенную группе процессов на этот период. Например, если мы хотим, чтобы наша группа процессов (приложение) получала доступ к процессорным ресурсам на одну десятую секунды каждую секунду, то нужно выполнить следующую команду:

$ sudo cgset -r cpu.cfs_period_us=1000000 -r cpu.cfs_quota_us=100000 sandbox

Обрати внимание, что данная настройка относится только к одному процессору, то есть на двухъядерной системе приложение будет получать процессор в два раза реже, а на четырехъядерной — в четыре раза реже. Еще один момент: данная настройка вовсе не значит, что приложение получит 10% процессорной мощности, она всего лишь гарантирует, что приложение не будет получать доступ к процессору реже, чем мы указали. Если система простаивает, то планировщик может выделить приложению гораздо больше времени для работы.

Ну и в завершение нам необходимо запустить наше приложение под управлением cgroups:

$ sudo cgexec -g cpu,memory:/sandbox ip netns exec unshare -piumU --fork --mount-proc chroot ~/sandbox /bin/ls -l /

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

 

Собираем все вместе

Теперь, когда мы знаем, как создать песочницу, мы можем написать скрипт, который делает это все за нас. Вот он:

#!/bin/bash

NAME=$1

# Создаем структуру каталогов
mkdir ~/sandbox
mkdir -p ~/sandbox/$NAME/{bin,sbin,etc,lib64,home,root,var,tmp}
mkdir -p ~/sandbox/$NAME/usr/{bin,sbin,lib}

# Копируем приложение
cp `which $NAME` ~/sandbox/$NAME/`which $NAME`

# Копируем линкер (он нужен всегда)
cp /lib64/ld-linux-x86-64.so.2 ~/sandbox/$NAME/lib64

# Получаем список библиотек приложения
libs=`ldd $(which $NAME) | grep -v linux-vdso.so.1 | grep -v ld-linux-x86-64.so.2 | cut -d " " -f 3`

# Копируем библиотеки
for lib in $libs; do
    cp $lib ~/sandbox/$NAME/$lib
done

# Поднимаем сетевой мост и создаем сетевое пространство имен
brctl addbr br0
brctl addif br0 eth0

ip netns add $NAME
ip link add veth1 type veth peer name eth1
ip link set eth1 netns $NAME

brctl addif br0 veth1
ip link set veth1 up
ip netns exec dhcpcd eth1

# Добавляем адрес DNS-сервера
echo 'nameserver 8.8.8.8' > ~/sandbox/$NAME/etc/resolv.conf

# Создаем cgroup
cgcreate -g cpu,memory:/$NAME
cgset -r memory.limit_in_bytes=128M $NAME
cgset -r cpu.cfs_period_us=1000000 -r cpu.cfs_quota_us=100000 $NAME

# Запускаем приложение в песочнице
cgexec -g cpu,memory:/$NAME ip netns exec unshare -piumU --fork --mount-proc chroot ~/sandbox/$NAME `which $NAME`

# Подчищаем за собой
cgdelete -g cpu,memory:/$NAME
ip netns delete $NAME
brctl delbr br0
rm -rf ~/sandbox/$NAME

Пользоваться скриптом очень просто. Достаточно просто указать имя приложения:

$ sudo sandbox.sh ps

Далее скрипт создаст выделенную песочницу в каталоге ~/sandbox, скопирует в него приложение и его зависимости, настроит сетевой мост и cgroups и запустит приложение, после чего удалит песочницу и сбросит настройки. Для простоты аргументы игнорируются. Также не пытайся с его помощью запустить сложный, а тем более графический софт, зависящий от файлов настроек и других данных, которые этот скрипт не умеет копировать в песочницу.

 

Выводы

Ядро Linux имеет все необходимые средства для создания изолированных окружений исполнения. Те же самые технологии можно использовать для запуска не только отдельно взятых приложений, но и целых дистрибутивов. Для этого достаточно скопировать в каталог песочницы все файлы дистрибутива, смонтировать каталоги /dev и /proc, а затем запустить /bin/init.

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

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

    • 5 комментариев к записи Собственный Docker. Создаем песочницу для приложений своими руками
    Подписаться
    Уведомить о
    5 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии