Quels sont les avantages et les inconvénients des conteneurs non privilégiés?

Réponses:

14

L'exécution de conteneurs non privilégiés est le moyen le plus sûr d'exécuter des conteneurs dans un environnement de production. Les conteneurs obtiennent une mauvaise publicité en matière de sécurité et l'une des raisons est que certains utilisateurs ont constaté que si un utilisateur obtient racine dans un conteneur, il est également possible d'obtenir la racine sur l'hôte. Fondamentalement, ce qu'un conteneur non privilégié fait est de masquer l'ID utilisateur de l'hôte. Avec des conteneurs non privilégiés, les utilisateurs non root peuvent créer des conteneurs et auront et apparaîtront dans le conteneur en tant que root, mais apparaîtront comme ID utilisateur 10000 par exemple sur l'hôte (quel que soit le mappage des ID utilisateur). J'ai récemment écrit un article de blog à ce sujet basé sur la série de blogs de Stéphane Graber sur LXC (l'un des esprits brillants / développeurs principaux de LXC et quelqu'un à suivre certainement). Je le répète, extrêmement brillant.

De mon blog:

Du conteneur:

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

De l'hôte:

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

Comme vous pouvez le voir, les processus s'exécutent à l'intérieur du conteneur en tant que root mais n'apparaissent pas en tant que root mais en tant que 100000 de l'hôte.

Donc, pour résumer: Avantages - sécurité accrue et isolation supplémentaire pour la sécurité. Inconvénient - Un peu déroutant pour envelopper votre tête au début et non pour l'utilisateur novice.

geekbass
la source
3
Donc, si je comprends bien, les conteneurs ne sont pas sécurisés à 100% par eux-mêmes. Quel que soit le conteneur que vous utilisez, il est possible que la bête puisse s'échapper. Et ce n'est qu'ici, lorsque le type de conteneur devient important. Pour les conteneurs privilégiés, la bête s'exécutera sous root, plantant des rootkits et grignotant de précieuses clés SSL. Pour les non privilégiés, il sera limité uniquement au compte d'utilisateur qui a créé le conteneur, non? Voler ses clés SSH, etc. Est-ce vraiment plus sûr? Peut-on l'expliquer avec une image de quatre boîtes imbriquées?
anatoly techtonik
2
En bref, les conteneurs eux-mêmes dès la sortie de la boîte ne sont pas sécurisés pour une utilisation en production. Traitez votre environnement LXC comme vous le feriez pour tout autre environnement Linux. Vous ne laisseriez pas votre boîte Linux grande ouverte non plus?! Oui, votre conteneur serait limité uniquement à celui auquel le compte d'utilisateur est mappé. Consultez la publication de Graber sur les conatiners non prouvés: je pense que le plus gros problème est de pouvoir exploiter le noyau et les appels système car chaque conteneur partage le même noyau. Il existe plusieurs façons d'améliorer la sécurité via des groupes de contrôle et d'autres applications comme selinux, apparmor et seccomp et plus encore.
geekbass
3
Stéphane Graber - stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers
geekbass
Créez donc un utilisateur limité distinct pour exécuter les conteneurs. Semble juste. J'accepte cela comme réponse. Merci.
anatoly techtonik
4

Ce sont des outils très précieux pour les tests, le sandboxing et l'encapsulation. Vous voulez qu'un serveur Web soit verrouillé en toute sécurité dans son propre environnement de travail, incapable d'accéder à des fichiers privés sensibles? Utilisez un conteneur. Vous avez une application qui nécessite d'anciennes versions de bibliothèques et des fichiers de configuration spécifiques, incompatibles avec d'autres applications? Aussi un conteneur. C'est fondamentalement chroot bien fait. Il vous permet de maintenir les services suffisamment séparés pour que la maintenance de chacun d'eux soit beaucoup plus facile, et ils peuvent être déplacés ou copiés sur une autre machine sans avoir à perturber le système existant.

L'inconvénient est que vous devez vous souvenir de l'espace de noms car presque tout est local au conteneur. Vous devez savoir où vous vous trouvez et la communication entre les conteneurs n'est pas anodine. C'est une bonne idée lorsque vous avez besoin de modularité, mais ne voulez pas les frais généraux des machines virtuelles, et les choses que vous gardez dans les conteneurs ne sont vraiment pas très liées.

Pour un utilisateur "ordinaire", vous pouvez utiliser des conteneurs pour utiliser une seule machine pour deux personnes tout en les gardant comme s'ils se trouvaient sur des machines complètement différentes. Colocataires, par exemple.

orion
la source
3
Bien qu'une bonne description humaine de ce à quoi servent les conteneurs, cela n'explique toujours pas la différence entre les conteneurs privilégiés et non privilégiés.
anatoly techtonik
1

Eh bien, avec un noyau partagé, bien qu'il augmente les exigences de l'adversaire de se libérer de certaines façons (ou plutôt; cela aide à limiter la surface d'attaque), les conteneurs non privilégiés ne sont toujours pas complètement isolés des hacks droits qui gagnent la racine de l'hôte, malgré cela .

Pour cette raison, c'est un peu une hypothèse / revendication erronée. Cela dit, le niveau d'aptitude technique de nombreux utilisateurs sur Internet fonctionnera toujours avec des services inets, d'une multitude de façons dont ils ne sont pas vraiment capables techniquement, alors bon. :)

Malina Salina
la source