Каковы преимущества и недостатки непривилегированных контейнеров?

Техническое объяснение того, что такое непривилегированный контейнер , довольно хорошее. Однако это не для обычного пользователя ПК. Есть ли простой ответ, когда и почему люди должны использовать непривилегированные контейнеры, каковы их преимущества и недостатки?

Запуск непривилегированных контейнеров - это самый безопасный способ запуска контейнеров в производственной среде. Контейнеры получают плохую огласку, когда речь заходит о безопасности, и одна из причин этого заключается в том, что некоторые пользователи обнаружили, что если пользователь получает root в контейнере, то также существует возможность получения root на хосте. В основном то, что делает непривилегированный контейнер, это маскирование идентификатора пользователя с хоста. С непривилегированными контейнерами пользователи без полномочий root могут создавать контейнеры и будут иметь и появляться в контейнере как root, но будут отображаться как ID пользователя 10000, например, на хосте (независимо от того, как вы отображаете идентификаторы пользователей). Недавно я написал пост в блоге об этом на основе серии блогов Стефана Грабера на 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

Как вы можете видеть, процессы внутри контейнера выполняются от имени пользователя root, но отображаются не как root, а как 100000 от хоста.

Итак, подведем итог: Преимущества - дополнительная безопасность и дополнительная изоляция для безопасности. Недостаток - сначала немного сбивает с толку, чтобы обернуть голову, а не для начинающего пользователя.

Это очень ценные инструменты для тестирования, песочницы и инкапсуляции. Хотите, чтобы веб-сервер был надежно заблокирован в собственной рабочей среде и не имел доступа к конфиденциальным файлам? Используйте контейнер. У вас есть приложение, для которого требуются старые версии библиотек и определенные файлы конфигурации, несовместимые с другими приложениями? Также контейнер. Это в основном chroot сделано правильно. Это позволяет вам поддерживать службы достаточно раздельно, поэтому обслуживание каждого из них намного проще, и их можно перемещать или копировать на другой компьютер, не нарушая работу существующей системы.

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

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

Что ж, с общим ядром, несмотря на то, что оно увеличивает требования противника к высвобождению в некотором смысле (точнее, помогает ограничить поверхность атаки), непривилегированные контейнеры все еще не полностью изолированы от прямых хаков, которые получают корень хоста, несмотря на это ,

По этой причине, это немного неправильное предположение / утверждение. Сказав это, уровень технических способностей у многих пользователей через Интернет будет по-прежнему запускать сервисы inet множеством способов, на которые они на самом деле технически не способны, так что, эй. :)