ПРОСТОРИ ІМЕН, ГРУПИ КЕРУВАННЯ (CGROUPS), ПРИВІЛЕЇ

Вступ: контейнер без віртуалізації заліза

Минулого разу ми з'ясували, що процес — це активна абстракція ядра: PID, адресний простір, дескриптори, права. Сьогодні ми відповідаємо на питання, яке напрошується само: якщо контейнер — це «просто процес», то як тоді всередині нього ps aux показує лише один-два рядки, а не сотні процесів хоста? Чому контейнер не бачить файлів хоста, хоча працює на тому самому ядрі? І чому один контейнер не може захопити всю оперативну пам'ять машини?

Відповідь — три незалежні механізми ядра Linux, які Docker комбінує, але не винаходить: простори імен (namespaces) визначають, що процес бачить, групи керування (cgroups) визначають, скільки процес може споживати, а capabilities визначають, що процесу дозволено робити. Жоден з цих механізмів не є специфічним для Docker — це базові примітиви ядра, доступні будь-якій програмі через звичайні системні виклики. Розуміння цього — ключ до того, щоб контейнери перестали здаватись магією.

Сім просторів імен ядра Linux

Простір імен — це механізм ядра, який дозволяє групі процесів мати власну, ізольовану «версію» певного глобального ресурсу ядра. Linux нині підтримує сім класичних видів просторів імен:

Кожен новий процес за замовчуванням успадковує простори імен свого батька. Але ядро дозволяє явно попросити нові, «чисті» простори — саме це і відбувається, коли Docker запускає контейнер.

Мережевий простір імен на практиці

NET namespace — один з найпоказовіших прикладів того, наскільки глибоко заходить ізоляція. Новостворений NET namespace стартує лише з loopback-інтерфейсом (lo), без жодного доступу до зовнішнього світу — навіть до Wi-Fi чи Ethernet хоста. Щоб з'єднати такий простір із рештою мережі, використовують віртуальну пару інтерфейсів veth (virtual Ethernet): один кінець лишається у вихідному просторі імен (зазвичай підключений до моста docker0 на хості), другий переноситься у новий простір. Пакет, надісланий з одного кінця пари, миттєво з'являється на іншому — це і є той «віртуальний кабель», яким Docker з'єднує контейнер з мережею хоста.

sudo ip netns add demo
sudo ip link add veth-host type veth peer name veth-ns
sudo ip link set veth-ns netns demo
sudo ip netns exec demo ip addr add 10.0.0.2/24 dev veth-ns

Саме тому кожен контейнер отримує власну IP-адресу, власну таблицю маршрутизації і власний набір правил файрвола (iptables/nftables), хоча фізично працює через той самий мережевий інтерфейс хоста.

clone(), unshare(), setns(): три способи роботи з просторами імен

Три системні виклики покривають увесь життєвий цикл роботи з просторами імен:

• clone(flags) — створює новий процес одразу в нових просторах імен. Прапорці на кшталт CLONE_NEWPID, CLONE_NEWNET, CLONE_NEWNS (mount), CLONE_NEWUTS, CLONE_NEWIPC, CLONE_NEWUSER, CLONE_NEWCGROUP вмикають потрібні простори саме для процесу, що народжується.
• unshare(flags) — «відв'язує» вже наявний процес від поточного простору імен і переводить його в новий. Саме на цьому побудована утиліта командного рядка unshare(1).
• setns(fd, nstype) — приєднує поточний процес до вже існуючого простору імен іншого процесу (через файловий дескриптор /proc/<pid>/ns/*). Саме так docker exec «заходить» усередину вже запущеного контейнера — не створює новий простір, а приєднується до наявного.

sudo unshare --pid --fork --mount-proc bash
# усередині:
ps aux      # видно лише bash і ps
echo $$     # 1

Прапорець --mount-proc тут критичний: без нього /proc усередині нового PID- простору лишається старим /proc хоста, і ps показуватиме процеси хоста, бо ps читає саме /proc, а не сам PID-простір напряму.

cgroups v2 — контроль апетиту

Namespaces вирішують питання видимості, але нічого не обмежують кількісно: без додаткового механізму один процес усередині «ізольованого» контейнера міг би виділити всю оперативну пам'ять хоста або завантажити всі ядра CPU на 100%. Цю прогалину закривають control groups (cgroups).

У сучасному Linux (cgroups v2, єдина уніфікована ієрархія) кожна група ресурсів — це каталог у /sys/fs/cgroup/, а ліміти й статистика — звичайні файли всередині нього:

docker run -d --name web --memory=100m --cpus=0.5 nginx
# Docker транслює це у файли cgroups v2, приблизно:
cat /sys/fs/cgroup/system.slice/docker-<id>.scope/memory.max   # 104857600
cat /sys/fs/cgroup/system.slice/docker-<id>.scope/cpu.max      # 50000 100000
docker stats --no-stream

memory.max — жорсткий ліміт: перевищення викликає OOM killer саме для процесів цієї групи, не чіпаючи решту хоста. cpu.max записаний як пара quota period (у мікросекундах): 50000 100000 означає «50 мс процесорного часу з кожних 100 мс», тобто половину одного ядра. cgroups v2 також контролюють I/O (io.max), кількість процесів (pids.max) — важливий захист від fork-бомб усередині контейнера — і hugetlb для великих сторінок пам'яті.

Linux capabilities: дроблення прав root

Класична модель Unix знає лише два стани: звичайний користувач і root (UID 0), який може все. Це занадто грубо для контейнерів: якщо процес усередині контейнера працює від root, а привілеї не роздроблені, компрометація контейнера дає атакуючому теоретично необмежені можливості в межах простору імен.

Capabilities дроблять «суперправа root» на близько 40 окремих дозволів. Кілька показових прикладів:

• CAP_NET_BIND_SERVICE — дозволяє прив'язатися до порту < 1024 без повного root;
• CAP_SYS_ADMIN — «звалище» найнебезпечніших адміністративних операцій (mount, деякі namespace-операції) — практично еквівалент часткового root, уникати за замовчуванням;
• CAP_NET_ADMIN — конфігурація мережевих інтерфейсів, маршрутів, фаєрвола;
• CAP_CHOWN, CAP_DAC_OVERRIDE — обхід перевірок власності й прав доступу до файлів.

Docker за замовчуванням запускає контейнери з обмеженим набором приблизно 14 capabilities (з ~40 доступних), явно відкидаючи найнебезпечніші. Побачити активний набір можна командою:

docker run --rm alpine sh -c "apk add -q libcap && capsh --print"
# Current: = cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,...

Прапорці --cap-add і --cap-drop дозволяють точково додати чи прибрати конкретну можливість без надання повного --privileged, який вимикає майже всі обмеження й має використовуватись лише як крайній випадок (наприклад, для Docker-in-Docker).

User namespaces: подвійний захист

USER namespace — окремий і особливо важливий випадок. Він дозволяє відобразити UID всередині простору імен на інший UID зовні. Класичний сценарій: процес усередині контейнера бачить себе як UID 0 (root) — і всередині простору імен це справді root з повним набором прав над файлами й процесами цього простору. Але зовні, з погляду хоста, той самий процес насправді виконується від непривілейованого UID (наприклад, 100000). Якщо атакуючий вирветься за межі namespace-ізоляції (через баг ядра чи неправильно змонтований шлях), на хості він матиме права звичайного користувача, а не root.

# Docker daemon.json: увімкнути user namespace remapping
{ "userns-remap": "default" }

Це — саме той «подвійний захист», про який ідеться в анонсі лекції: навіть якщо namespaces і capabilities десь дадуть слабину, user namespace робить компрометацію контейнера значно менш цінною для атакуючого.

Разом: з чого складається контейнер

Жоден з трьох механізмів окремо не дає повної ізоляції:

• namespaces відповідають на питання «що процес бачить» — власний PID, мережу, файлову систему, hostname, IPC, UID-мапінг, cgroup-ієрархію;
• cgroups відповідають на питання «скільки процес може споживати» — CPU, пам'ять, I/O, кількість процесів;
• capabilities відповідають на питання «що процесу дозволено робити», навіть якщо він формально root усередині свого простору імен.

Docker (і containerd, runc під ним) — це, по суті, зручна оркестрація виклику clone() з правильним набором прапорців, запис лімітів у файли cgroups v2 і виставлення набору capabilities — усе перед тим, як зрештою викликати execve() над процесом усередині контейнера.

Важливо, що жоден з трьох механізмів не «знає» про існування двох інших: ядро надає cgroups тому самому процесу незалежно від того, чи має він власний PID namespace, і namespaces працюють так само для процесу з повним набором capabilities чи без нього. Docker (через runc, низькорівневий OCI-рантайм) просто послідовно застосовує всі три механізми до одного й того самого clone()-виклику — саме ця комбінаторність і дає враження «окремого контейнера», хоча насправді це один процес, до якого застосували три незалежні, ортогональні обмеження ядра.

Підводні камені

• unshare --pid без --mount-proc лишає /proc від хоста — ps покаже «чужі» процеси, бо читає старий /proc, хоча PID-простір насправді новий.
• cgroups v1 vs v2 — старі системи (і деякі дистрибутиви) досі можуть мати змішану або v1-ієрархію; шляхи /sys/fs/cgroup/memory/... (v1) відрізняються від єдиної ієрархії v2.
• --privileged — не «більше прав», а «майже всі прапорці ISOLATION вимкнено»: він одночасно дає всі capabilities, вимикає seccomp-профіль і відкриває доступ до пристроїв хоста — це надзвичайно широкий дозвіл, а не точкове налаштування.
• root у контейнері без user namespace — реальний root на хості, якщо процес зуміє вирватись за межі mount/PID namespace через вразливість.
• cgroups memory.max ≠ гарантія OOM усередині контейнера: OOM killer у cgroup вбиває конкретний процес усередині групи, але сама група (і контейнер) може продовжити працювати в деградованому стані.

Підсумок

Контейнер — не окрема машина й не легка віртуальна машина, а звичайний Linux-процес, якому через сім видів просторів імен підмінили видимість світу, через cgroups v2 обмежили споживання ресурсів, а через capabilities роздробили права root на окремі дозволи. clone(), unshare() і setns() — три системні виклики, що покривають увесь життєвий цикл роботи з просторами імен, включно з тим, як docker exec приєднується до вже запущеного контейнера. User namespace додає ще один рівень захисту, відображаючи UID 0 усередині на непривілейований UID зовні. Наступна лекція переходить від запущеного контейнера (runtime) до самого образу: з чого він складається, чому важить саме стільки й що таке шари.