Технічне пояснення того, що таке непривілейований контейнер, є досить хорошим. Однак це не для звичайного користувача ПК. Чи є проста відповідь, коли і чому люди повинні використовувати непривітні контейнери, і які їх переваги та недоліки?
Технічне пояснення того, що таке непривілейований контейнер, є досить хорошим. Однак це не для звичайного користувача ПК. Чи є проста відповідь, коли і чому люди повинні використовувати непривітні контейнери, і які їх переваги та недоліки?
Відповіді:
Запуск непривілейованих контейнерів є найбезпечнішим способом запуску контейнерів у виробничих умовах. Контейнери отримують погану рекламу, якщо мова йде про безпеку, і одна з причин полягає в тому, що деякі користувачі виявили, що якщо користувач отримує корінь у контейнері, то існує можливість отримати корінь і на хості. В основному те, що робить непривілейований контейнер, це маскувати userid від хоста. З непривілейованими контейнерами, некористувальні користувачі можуть створювати контейнери і матимуть і відображатимуться в контейнері як корінь, але вони будуть відображатися як userid 10000, наприклад на хості (як би ви не вказали користувальницькі користувачі). Нещодавно я написав публікацію в блозі на основі серіалу блогу Стефана Грабера на LXC (один з геніальних розробників LXC та головний розробник LXC). Я знову кажу, надзвичайно блискуче.
З мого блогу:
З контейнера:
lxc-attach -n ubuntu-unprived
root@ubuntu-unprived:/# ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 04:48 ? 00:00:00 /sbin/init
root 157 1 0 04:48 ? 00:00:00 upstart-udev-bridge --daemon
root 189 1 0 04:48 ? 00:00:00 /lib/systemd/systemd-udevd --daemon
root 244 1 0 04:48 ? 00:00:00 dhclient -1 -v -pf /run/dhclient.eth0.pid
syslog 290 1 0 04:48 ? 00:00:00 rsyslogd
root 343 1 0 04:48 tty4 00:00:00 /sbin/getty -8 38400 tty4
root 345 1 0 04:48 tty2 00:00:00 /sbin/getty -8 38400 tty2
root 346 1 0 04:48 tty3 00:00:00 /sbin/getty -8 38400 tty3
root 359 1 0 04:48 ? 00:00:00 cron
root 386 1 0 04:48 console 00:00:00 /sbin/getty -8 38400 console
root 389 1 0 04:48 tty1 00:00:00 /sbin/getty -8 38400 tty1
root 408 1 0 04:48 ? 00:00:00 upstart-socket-bridge --daemon
root 409 1 0 04:48 ? 00:00:00 upstart-file-bridge --daemon
root 431 0 0 05:06 ? 00:00:00 /bin/bash
root 434 431 0 05:06 ? 00:00:00 ps -ef
Від господаря:
lxc-info -Ssip --name ubuntu-unprived
State: RUNNING
PID: 3104
IP: 10.1.0.107
CPU use: 2.27 seconds
BlkIO use: 680.00 KiB
Memory use: 7.24 MiB
Link: vethJ1Y7TG
TX bytes: 7.30 KiB
RX bytes: 46.21 KiB
Total bytes: 53.51 KiB
ps -ef | grep 3104
100000 3104 3067 0 Nov11 ? 00:00:00 /sbin/init
100000 3330 3104 0 Nov11 ? 00:00:00 upstart-udev-bridge --daemon
100000 3362 3104 0 Nov11 ? 00:00:00 /lib/systemd/systemd-udevd --daemon
100000 3417 3104 0 Nov11 ? 00:00:00 dhclient -1 -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0
100102 3463 3104 0 Nov11 ? 00:00:00 rsyslogd
100000 3516 3104 0 Nov11 pts/8 00:00:00 /sbin/getty -8 38400 tty4
100000 3518 3104 0 Nov11 pts/6 00:00:00 /sbin/getty -8 38400 tty2
100000 3519 3104 0 Nov11 pts/7 00:00:00 /sbin/getty -8 38400 tty3
100000 3532 3104 0 Nov11 ? 00:00:00 cron
100000 3559 3104 0 Nov11 pts/9 00:00:00 /sbin/getty -8 38400 console
100000 3562 3104 0 Nov11 pts/5 00:00:00 /sbin/getty -8 38400 tty1
100000 3581 3104 0 Nov11 ? 00:00:00 upstart-socket-bridge --daemon
100000 3582 3104 0 Nov11 ? 00:00:00 upstart-file-bridge --daemon
lxc 3780 1518 0 00:10 pts/4 00:00:00 grep --color=auto 3104
Як ви бачите, процеси протікають всередині контейнера як корінь, але з'являються не як корінь, а як 100000 від хоста.
Отже, підводячи підсумок: Переваги - додаткова безпека та додаткова ізоляція для безпеки. Даунсайд - Спочатку трохи заплутано обернути голову, а не для початківця користувача.
Вони є дуже цінними інструментами для тестування, пісочниці та інкапсуляції. Хочете, щоб веб-сервер був безпечно заблокований у своєму робочому середовищі, не маючи доступу до конфіденційних приватних файлів? Використовуйте контейнер. У вас є програма, яка вимагає старих версій бібліотек та певних файлів конфігурації, несумісних з іншими програмами? Також контейнер. Це в основному chroot зроблено правильно. Це дозволяє підтримувати сервіси досить окремими, тому обслуговування кожного з них набагато простіше, і їх можна перемістити або скопіювати на іншу машину, не порушуючи існуючої системи.
Мінус полягає в тому, що вам потрібно запам’ятати простір імен, щоб майже все було локальним для контейнера. Ви повинні знати про те, де ви знаходитесь, і спілкування між контейнерами не є банальним. Це гарна ідея, коли вам потрібна модульність, але не хочете, щоб накладні витрати віртуальних машин, і речі, які ви зберігаєте в контейнерах, насправді не дуже пов’язані.
Для "звичайного" користувача ви можете використовувати контейнери, щоб використовувати одну машину для двох людей, зберігаючи їх так, ніби вони знаходяться на абсолютно різних машинах. Наприклад, сусідки по кімнаті.
Що ж, з загальним ядром, незважаючи на те, що він збільшує вимоги супротивника звільнитись якимось чином (а точніше, це сприяє обмеженню поверхні атаки), непривілейовані контейнери все ще не є повністю ізольованими від прямих хак, які отримують root root, незважаючи на це .
З цієї причини це трохи неправильне припущення / твердження. Сказавши це, рівень технічної здатності у багатьох користувачів в Інтернеті все ще працюватиме в службах inet безліччю способів, на які вони насправді не здатні, так що. :)