Jakie są zalety i wady nieuprzywilejowanych kontenerów?

Odpowiedzi:

14

Uruchamianie nieuprzywilejowanych kontenerów jest najbezpieczniejszym sposobem uruchamiania kontenerów w środowisku produkcyjnym. Kontenery zyskują zły rozgłos, jeśli chodzi o bezpieczeństwo, a jednym z powodów jest to, że niektórzy użytkownicy stwierdzili, że jeśli użytkownik zrootuje się w kontenerze, istnieje również możliwość uzyskania roota na hoście. Zasadniczo to, co robi nieuprzywilejowany kontener, to maskowanie identyfikatora użytkownika z hosta. W nieuprzywilejowanych kontenerach użytkownicy niebędący rootami mogą tworzyć kontenery i będą mieć i pojawiać się w kontenerze jako root, ale pojawią się jako identyfikator użytkownika 10000 na przykład na hoście (niezależnie od tego, jak mapuje się identyfikatory użytkownika). Niedawno napisałem na ten temat post na blogu w oparciu o serię blogów Stephane Grabera na LXC (jeden z genialnych umysłów / wiodących twórców LXC i ktoś, kogo zdecydowanie należy śledzić). Mówię ponownie, niezwykle błyskotliwy.

Z mojego bloga:

Z pojemnika:

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

Z hosta:

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

Jak widać procesy działają w kontenerze jako root, ale nie pojawiają się jako root, ale jako 100000 od hosta.

Podsumowując: Korzyści - dodatkowe bezpieczeństwo i dodatkowa izolacja dla bezpieczeństwa. Wada - trochę mylące, aby najpierw owinąć głowę, a nie dla początkującego użytkownika.

geekbass
źródło
3
Tak więc, jeśli dobrze to rozumiem, kontenery same w sobie nie są w 100% bezpieczne. Bez względu na to, z którego pojemnika korzystasz, bestia może uciec. I to tylko tutaj, kiedy rodzaj pojemnika staje się ważny. W przypadku uprzywilejowanych kontenerów bestia będzie działała dziko pod rootem, sadząc rootkity i chrupiąc cenne klucze SSL. Dla osób nieuprzywilejowanych będzie to ograniczone tylko do konta użytkownika, które utworzyło kontener, prawda? Kradzież jego kluczy SSH itp. Czy to naprawdę bezpieczniejsze? Czy można to wytłumaczyć obrazem czterech zagnieżdżonych skrzynek?
anatoly techtonik
2
Krótko mówiąc, same pojemniki zaraz po wyjęciu z pudełka nie są bezpieczne do użytku produkcyjnego. Traktuj swoje środowisko LXC jak każde inne środowisko Linux. Nie zostawiłbyś swojego Linux-a szeroko otwartego, prawda ?! Tak, twój kontener będzie ograniczony tylko do tego, na które konto użytkownika jest mapowane. Sprawdź post Grabera na temat nieprywatnych konatatatorów: Myślę, że największym problemem jest możliwość wykorzystania jądra i wywołań systemowych, ponieważ każdy kontener ma to samo jądro. Istnieje kilka sposobów na zwiększenie bezpieczeństwa za pomocą cgroups i innych aplikacji, takich jak selinux, apparmor i seccomp i więcej.
geekbass
3
Stéphane Graber - stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers
geekbass
Utwórz osobnego ograniczonego użytkownika do uruchamiania kontenerów. Wydaje się sprawiedliwy. Przyjmuję to jako odpowiedź. Dzięki.
anatoly techtonik
4

Są to bardzo cenne narzędzia do testowania, piaskownicy i enkapsulacji. Chcesz, aby serwer WWW był bezpiecznie zablokowany we własnym środowisku roboczym i nie mógł uzyskać dostępu do poufnych plików prywatnych? Użyj pojemnika. Masz aplikację, która wymaga starych wersji bibliotek i określonych plików konfiguracyjnych, niezgodnych z innymi aplikacjami? Również pojemnik. Zasadniczo jest to chroot zrobione dobrze. Pozwala to na utrzymanie usług na tyle osobnych, że utrzymanie każdej z nich jest znacznie łatwiejsze, i można je przenosić lub kopiować na inną maszynę bez konieczności naruszania istniejącego systemu.

Minusem jest to, że musisz pamiętać przestrzeń nazw dla prawie wszystkiego, co jest lokalne dla kontenera. Musisz wiedzieć, gdzie jesteś, a komunikacja między kontenerami nie jest trywialna. Jest to dobry pomysł, gdy potrzebujesz modułowości, ale nie chcesz narzutu maszyn wirtualnych, a rzeczy, które trzymasz w kontenerach, nie są zbytnio powiązane.

Dla „zwykłego” użytkownika możesz użyć kontenerów, aby używać jednej maszyny dla dwóch osób, zachowując je tak, jakby były na zupełnie innych maszynach. Na przykład współlokatorzy.

orion
źródło
3
Chociaż dobry opis tego, do czego służą kontenery, wciąż nie wyjaśnia różnicy między uprzywilejowanymi a nieuprzywilejowanymi.
anatoly techtonik
1

Cóż, ze wspólnym jądrem, pomimo że zwiększa on wymagania przeciwnika do uwolnienia się w jakiś sposób (a raczej; pomaga to ograniczyć powierzchnię ataku), nieuprzywilejowane kontenery wciąż nie są całkowicie izolowane od prostych włamań, które zyskują root root, pomimo tego .

Z tego powodu jest to trochę błędne założenie / roszczenie. To powiedziawszy, poziom umiejętności technicznych wielu użytkowników w Internecie będzie nadal obsługiwał usługi internetowe, na wiele sposobów, do których tak naprawdę nie są technicznie zdolni, więc hej. :)

Malina Salina
źródło