¿Cuáles son los beneficios y desventajas de los envases sin privilegios?

Respuestas:

14

Ejecución de contenedores sin privilegios es la forma más segura para funcionar contenedores en un entorno de producción. Contenedores obtienen mala publicidad cuando se trata de seguridad y una de las razones es debido a que algunos usuarios han encontrado que si un usuario obtiene de la raíz en un recipiente, entonces hay una posibilidad de obtener root en el host también. Básicamente lo que un contenedor sin privilegios hace es enmascarar el identificador de usuario desde el host. Con contenedores sin privilegios, los usuarios no root pueden crear contenedores y tendrán y aparecen en el envase como root, pero aparecerán como identificador de usuario 10000, por ejemplo, en el host (lo que en el mapa los identificadores de usuario AS). Recientemente escribí una publicación de blog sobre esto basada en la serie de blogs de Stephane Graber en LXC (Una de las mentes brillantes / desarrolladores principales de LXC y alguien a quien definitivamente seguir). Digo de nuevo, muy brillante.

Desde mi blog:

Del contenedor:

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

Del anfitrión:

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

Como puede ver, los procesos se ejecutan dentro del contenedor como root, pero no aparecen como root, sino como 100000 desde el host.

En resumen: Beneficios: seguridad adicional y aislamiento adicional para la seguridad. Desventaja: un poco confuso para entender al principio y no para el usuario novato.

geekbass
fuente
3
Entonces, si lo entiendo correctamente, los contenedores no son 100% seguros por sí mismos. No importa qué contenedor ejecutes, existe la posibilidad de que la bestia pueda escapar. Y es solo aquí, cuando el tipo de contenedor se vuelve importante. Para contenedores privilegiados, la bestia se ejecutará salvajemente bajo la raíz, plantando rootkits y masticando valiosas claves SSL. Para los no privilegiados se limitará solo a la cuenta de usuario que creó el contenedor, ¿verdad? Robar sus claves SSH, etc. ¿Es eso realmente más seguro? ¿Se puede explicar con una imagen de cuatro cajas anidadas?
anatoly techtonik
2
En resumen, los contenedores directamente listos para usar no son seguros para su uso en producción. Trate su entorno LXC como lo haría con cualquier otro entorno Linux. ¿No dejarías tu caja de Linux abierta de par en par tampoco? Sí, su contenedor estará limitado solo a la asignación de la cuenta de usuario. Echa un vistazo a la publicación de Graber sobre contenedores no privados: creo que el mayor problema es poder explotar el kernel y las llamadas al sistema porque cada contenedor comparte el mismo kernel. Hay varias formas de mejorar la seguridad a través de cgroups y otras aplicaciones como selinux, apparmor y seccomp y más.
geekbass
3
Stéphane Graber - stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers
geekbass
Por lo tanto, cree un usuario limitado separado para ejecutar contenedores. Parece justo. Acepto esto como la respuesta. Gracias.
anatoly techtonik
4

Son herramientas muy valiosas para pruebas, sandboxing y encapsulación. ¿Desea que un servidor web esté bloqueado de forma segura en su propio entorno de trabajo, sin poder acceder a archivos privados confidenciales? Usa un recipiente. ¿Tiene una aplicación que requiere versiones antiguas de bibliotecas y archivos de configuración específicos, incompatibles con otras aplicaciones? También un contenedor. Básicamente es chroot bien hecho. Le permite mantener los servicios lo suficientemente separados para que mantenerlos sea mucho más fácil, y se pueden mover o copiar a otra máquina sin tener que alterar el sistema existente.

La desventaja es que debe recordar el espacio de nombres para casi todo lo que es local en el contenedor. Debe estar consciente de dónde se encuentra, y la comunicación entre contenedores no es trivial. Es una buena idea cuando necesita modularidad, pero no quiere la sobrecarga de las máquinas virtuales, y las cosas que guarda en contenedores realmente no están muy relacionadas.

Para un usuario "ordinario", puede usar contenedores para usar una sola máquina para dos personas mientras los mantiene como si estuvieran en máquinas completamente diferentes. Compañeros de cuarto, por ejemplo.

Orión
fuente
3
Si bien una buena descripción humana de para qué son los contenedores, esto aún no explica la diferencia entre los privilegiados y los no privilegiados.
anatoly techtonik
1

Bueno, con un kernel compartido, a pesar de que aumenta los requisitos del adversario para liberarse de alguna manera (o más bien, ayuda a limitar la superficie de ataque), los contenedores no privilegiados aún no están completamente aislados de los hacks rectos que obtienen la raíz del host, a pesar de esto .

Por esa razón, es una suposición / afirmación un poco errónea. Dicho esto, el nivel de aptitud técnica en muchos usuarios a través de Internet seguirá ejecutando servicios inet, en una multitud de formas de las que no son técnicamente capaces, así que oye. :)

Malina Salina
fuente