Quais são os benefícios e desvantagens de contêineres não privilegiados?

Question

A explicação técnica do recipiente sem privilégios é bastante boa . No entanto, não é para o usuário comum de PC. Existe uma resposta simples quando e por que as pessoas devem usar contêineres não-autorizados, e quais são seus benefícios e desvantagens?

    

Answer 1

A execução de contêineres desprivilegiados é a maneira mais segura de executar contêineres em um ambiente de produção. Os contêineres recebem publicidade ruim quando se trata de segurança e uma das razões é porque alguns usuários descobriram que, se um usuário obtém root em um contêiner, existe a possibilidade de obter raiz no host também. Basicamente, o que um container não privilegiado faz é mascarar o userid do host. Com contêineres não privilegiados, os usuários não raiz podem criar contêineres e aparecerão e aparecerão no contêiner como raiz, mas aparecerão como ID do usuário 10000, por exemplo, no host (seja lá como você mapear os IDs do usuário). Recentemente, escrevi um post sobre isso com base no blog de Stephane Graber

Do meu blog:

Do contêiner:

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

Do host:

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 você pode ver, os processos estão sendo executados dentro do container como root, mas não estão aparecendo como root, mas como 100000 do host.

Então, para resumir: Benefícios - segurança adicional e isolamento adicional para segurança. Desvantagem - Um pouco confuso para envolver sua cabeça em primeiro lugar e não para o usuário iniciante.

    

Answer 2

São ferramentas muito valiosas para testes, sandbox e encapsulamento. Deseja que um servidor da Web seja bloqueado com segurança em seu próprio ambiente de trabalho, incapaz de acessar arquivos confidenciais confidenciais? Use um contêiner. Você tem um aplicativo que requer versões antigas de bibliotecas e arquivos de configuração específicos, incompatíveis com outros aplicativos? Também um contêiner. É basicamente chroot feito certo. Ele permite que você mantenha os serviços separados o suficiente para manter cada um deles muito mais fácil, e eles podem ser movidos ou copiados para outra máquina sem ter que perturbar o sistema existente.

A desvantagem é que você precisa se lembrar do namespace para quase tudo é local para o contêiner. Você precisa estar ciente de onde está e a comunicação entre os contêineres não é trivial. É uma boa ideia quando você precisa de modularidade, mas não quer a sobrecarga das máquinas virtuais, e as coisas que você guarda nos contêineres não são realmente muito relacionadas.

Para um usuário "comum", é possível usar contêineres para usar uma única máquina para duas pessoas, mantendo-as como se estivessem em máquinas completamente diferentes. Colegas de quarto, por exemplo.

    

Answer 3

Bem, com um kernel compartilhado, apesar de aumentar os requisitos do adversário para se libertar de alguma forma (ou melhor, ele ajuda a limitar a superfície de ataque), os contêineres não privilegiados ainda não estão completamente isolados dos hacks diretos que ganham raiz do host , apesar disso.

Por essa razão, é uma suposição / reivindicação errada. Dito isto, o nível de aptidão técnica em muitos usuários através da Internet ainda executará serviços inet, de várias maneiras que eles não são tecnicamente capazes, então, ei. :)