Sicurezza di LXC rispetto a OpenVZ

Question

Sicurezza di LXC rispetto a OpenVZ

#1 da (2 voti)
#2 da (1 voti)

6

Per anni, sto usando OpenVZ sul mio server, ma supporto sospeso per Debian e Ubuntu, le attuali versioni sembrano concentrarsi su LXC ora, che non è una cattiva idea dal punto di vista del comfort.

Ma per quanto riguarda la sicurezza? Ricordo di aver letto una volta che LXC non fornisce lo stesso livello di separazione dei processi e dei contenitori rispetto a OpenVZ. Purtroppo, non riesco più a trovare il documento, ma sono d'accordo che potrebbero esserci alcuni problemi di sicurezza almeno nella configurazione predefinita di LXC. Ad esempio, con un rootfs completamente personalizzato, ho gestito una volta (in una versione precedente di LXC) per modificare il terminale dell'host da un contenitore LXC utilizzando chvt 1 e premendo Ctrl + C terminato in un riavvio del mio ambiente X11 quando ho provato a riprodurre oggi. Lo so, tutte le soluzioni container utilizzano lo stesso kernel e un hack del kernel può portare a un breakout del contenitore, non è quello che chiedo. Ma non dovrebbe essere così facile influenzare l'host o altri contenitori da un contenitore.

Quanta sicurezza posso aspettarmi da OpenVZ e LXC?

Il mio server espone alcune porte guest a Internet, quindi mi interessa davvero questo aspetto, ma devo prendere una decisione perché gli strumenti attualmente utilizzati devono essere aggiornati. L'uso di KVM o simili non è un'opzione dal momento che il mio server ha una CPU a basse prestazioni.

PS: sto parlando della vera implementazione di OpenVZ con vzctl 4.7.2-1. Alcune implementazioni più recenti di vzctl usano tecniche LXC.

linux virtualization

posta Daniel Alder 31.01.2015 - 14:18

fonte

2 risposte

Leggi altre domande sui tag linux virtualization

Qualsiasi browser non totalmente insicuro vulnerabile a BEAST? La separazione dei dati da diverse applicazioni tramite gli schemi Oracle è considerata sicura?

score 2 · Answer 1

(Disclaimer: I am not un'autorità su OpenVZ. Questa risposta è più supponente delle mie risposte di solito, quindi sentiti libero di criticare!)

OpenVZ potrebbe essere "più" sicuro in quanto non si integra con l'intero kernel, così che la sua superficie di attacco è un po 'più bassa. Anche se, essenzialmente OpenVZ è ciò che è servito come ispirazione per gli spazi dei nomi e quindi, in definitiva, LXC e Docker. Non credo che continueremo per molto tempo ora che quelle soluzioni più complete sono, beh, complete.

Come sottolineato da WhiteWinterWolf una delle grandi differenze è che finalmente LXC può utilizzare lo spazio dei nomi utente, aprendo la possibilità agli utenti non privilegiati di eseguire i contenitori e garantire che il codice contenuto che esce dal contenitore mantenga i privilegi degli utenti non privilegiati. Inoltre, i contenitori basati sullo spazio dei nomi potrebbero essere completamente etichettati con SELinux. Normalmente i container Docker sono già, e Dan Walsh sta lavorando su un modo per far sì che SELinux imponga automaticamente un ulteriore livello di isolamento tra i contenitori utilizzando categorie generate casualmente per i processi contenuti.

Quindi, in sintesi, i contenitori sono migliori perché: - Possono parzialmente ostacolare alcuni breakout del contenitore (limitandoli a un UID non privilegiato), rendendo irrilevanti le escalation di privilegi all'interno del contenitore. - Sono più supportati e più attivamente sviluppati, e in particolare trarranno grandi benefici dal supporto di SELinux.

E sono peggio perché: - Il loro TCB è molto grande, attraverso l'intero kernel e si verificheranno bug ogni tanto portando a exploit e breakouts. - Lo spazio dei nomi utente mi sembra una specie di caso limite. Solitamente ottieni l'escalation dei privilegi tramite un bug nel SCI (che potresti riprodurre dopo il breakout) o attacchi delegati confusi su un servizio privilegiato (che è probabile che mantengano esistenti al di fuori del tuo contenitore in primo luogo). Pertanto, dovrai comunque limitare strettamente l'UID che esegue il contenitore ai contenitori in esecuzione.

In sintesi, continua a praticare la difesa in profondità e continua a pensare a come lasciare che i processi contenuti interagiscano con il mondo esterno e come gestisci i contenitori. Le differenze esistono ma, come puoi vedere, sono piuttosto minime.

score 1 · Answer 2

Una delle tecniche di sicurezza più nuove e più promettenti specifiche per LXC è l'utilizzo di contenitori a basso privilegio, il che è possibile solo grazie alla stretta integrazione di LXC all'interno del kernel Linux. Si affida agli spazi dei nomi degli utenti che consentono agli utenti all'interno di LXC di essere visti come una sorta di "sub-utenti" dal proprietario del contenitore.

Se il proprietario del contenitore è root, come è richiesto per la maggior parte dei sistemi simili a container, questo non cambierà nulla in termini di sicurezza (o almeno in modo notevole). Tuttavia, la "magia" qui è che il contenitore può essere di proprietà di un utente non privilegiato, e in questo caso l'utente root del contenitore avrà lo stesso privilegio sul sistema come proprietario del contenitore, es. l'utente non privilegiato.

Una buona fonte di informazioni su tutto questo proviene da Stéphane Grabers 'blog , uno degli sviluppatori coinvolti nel progetto LXC.