Techniczne wyjaśnienie, czym jest nieuprzywilejowany pojemnik, jest całkiem dobre. Jednak nie jest to dla zwykłego użytkownika komputera. Czy istnieje prosta odpowiedź na pytanie, kiedy i dlaczego ludzie powinni używać nieuprzywilejowanych pojemników oraz jakie są ich zalety i wady?
Odpowiedzi:
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.
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.
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. :)