La explicación técnica de lo que es sin privilegios envase es bastante bueno. Sin embargo, no es para un usuario normal de PC. ¿Hay una respuesta simple y cuándo y por qué la gente debe utilizar recipientes unpriviliged, y cuáles son sus ventajas y desventajas?
Respuestas:
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.
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.
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. :)