La spiegazione tecnica di ciò che è un contenitore senza privilegi è abbastanza buona. Tuttavia, non è per un normale utente di PC. C'è una risposta semplice quando e perché le persone dovrebbero usare contenitori non privilegiati e quali sono i loro vantaggi e svantaggi?
Risposte:
L'esecuzione di contenitori non privilegiati è il modo più sicuro per eseguire contenitori in un ambiente di produzione. I contenitori ottengono cattiva pubblicità quando si tratta di sicurezza e uno dei motivi è perché alcuni utenti hanno scoperto che se un utente ottiene root in un contenitore, c'è anche la possibilità di ottenere root anche sull'host. Fondamentalmente ciò che fa un contenitore senza privilegi è mascherare l'id utente dall'host. Con contenitori non privilegiati, gli utenti non root possono creare contenitori e avranno e appariranno nel contenitore come root ma appariranno come userid 10000, ad esempio sull'host (qualunque sia la mappa degli userid come). Di recente ho scritto un post sul blog basato sulla serie di blog di Stephane Graber su LXC (Una delle menti brillanti / principali sviluppatori di LXC e qualcuno da seguire definitivamente). Ripeto, estremamente brillante.
Dal mio blog:
Dal contenitore:
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
Dall'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
Come puoi vedere, i processi sono in esecuzione all'interno del contenitore come root ma non vengono visualizzati come root ma come 100000 dall'host.
Per riassumere: Vantaggi: maggiore sicurezza e maggiore isolamento per la sicurezza. Unico inconveniente: un po 'confuso per avvolgere la testa all'inizio e non per l'utente inesperto.
Sono strumenti molto preziosi per test, sandboxing e incapsulamento. Vuoi che un server web sia bloccato in modo sicuro nel proprio ambiente di lavoro, incapace di accedere a file privati sensibili? Usa un contenitore. Hai un'applicazione che richiede vecchie versioni di librerie e file di configurazione specifici, incompatibili con altre applicazioni? Anche un contenitore. Fondamentalmente è chroot fatto bene. Ti consente di mantenere i servizi abbastanza separati in modo che mantenerli ognuno sia molto più semplice e possono essere spostati o copiati su un altro computer senza dover disturbare il sistema esistente.
Il rovescio della medaglia è che è necessario ricordare lo spazio dei nomi per quasi tutto è locale al contenitore. Devi essere consapevole di dove ti trovi e la comunicazione tra contenitori non è banale. È una buona idea quando hai bisogno di modularità, ma non vuoi il sovraccarico delle macchine virtuali e le cose che conservi nei container non sono molto correlate.
Per un utente "normale", è possibile utilizzare i contenitori per utilizzare una macchina singola per due persone, mantenendoli come se fossero su macchine completamente diverse. Compagni di stanza, per esempio.
Bene, con un kernel condiviso, nonostante aumenti i requisiti dell'avversario per liberarsi in qualche modo (o meglio; aiuta a limitare la superficie di attacco), i contenitori non privilegiati non sono ancora completamente isolati da hack diritti che ottengono il root dell'host, nonostante questo .
Per tale motivo, si tratta di un'ipotesi / affermazione un po 'sbagliata. Detto questo, il livello di attitudine tecnica in molti utenti su Internet continuerà a funzionare con servizi inet, in una moltitudine di modi di cui non sono tecnicamente in grado, quindi ehi. :)