Se un contenitore è compromesso, significa che anche l'host è compromesso?

Se il kernel è compromesso nel contenitore, l'host è compromesso.

Apparentemente, un contenitore compromesso non dovrebbe essere in grado di danneggiare l'host. Tuttavia, la sicurezza del contenitore non è eccezionale e di solito esistono molte vulnerabilità che consentono a un utente con contenitore privilegiato di compromettere l'host. In questo modo, i contenitori sono spesso meno sicuri rispetto alle macchine virtuali complete. Ciò non significa che le macchine virtuali non possano essere compromesse . Non sono abbastanza come male.

Se il kernel viene sfruttato in una macchina virtuale, l'autore dell'attacco deve ancora trovare un bug nell'hypervisor. Se il kernel viene sfruttato in un contenitore, l'intero sistema viene compromesso, incluso l'host. Ciò significa che i bug di sicurezza del kernel, come classe, sono molto più severi quando vengono utilizzati i contenitori.

I contenitori vengono spesso implementati utilizzando spazi dei nomi :

A namespace wraps a global system resource in an abstraction that makes it appear to the process within the namespace that they have their own isolated instance of a global resource. Changes to the global resource are visible to other processes that are members of the namespace, but are invisible to other processes.

Sfortunatamente, i namespace Linux espongono tipicamente un'area di attacco molto più grande dal kernel. Molti kernel vulnerabilità sono utilizzabile nei namespace. Sebbene non tutte le soluzioni di container utilizzino i namespace di Linux, tutte utilizzano lo stesso tipo di tecnologia, con gli stessi problemi di sicurezza . Alcuni contenitori, come Docker, sono in grado di utilizzare un framework di filtraggio syscall chiamato seccomp per ridurre l'area di superficie di attacco del kernel. Questo è un miglioramento, ma non sempre è sufficiente.

Da Daniel Shapira :

[...] kernel exploits can be devastating for containerized environments. This is because containers share the same kernel as the host, thus trusting the built-in protection mechanisms alone isn’t sufficient.

Poiché i contenitori non sono isolati come le macchine virtuali, sì, in un modo sono meno sicuri. Vedi la risposta della foresta.

Detto questo, penso che valga la pena notare che i container offrono anche alcuni vantaggi dal punto di vista della sicurezza delle applicazioni. Poiché in genere eseguono un singolo processo, limitano la superficie di attacco, ad esempio non ci sono monitor cron o ssh daemon in esecuzione all'interno del contenitore. Le immagini del contenitore sono immutabili: al riavvio caricano dai binari originali. Non è possibile sovrascrivere l'applicazione. La maggior parte delle tecnologie dei container consente anche un controllo preciso su quali porte sono aperte ea chi. Puoi avere un contenitore per un DB a cui non è possibile accedere da qualsiasi altro oltre ai tuoi altri contenitori.

Tutto ciò presuppone che queste funzionalità funzionino come pubblicizzate e che non abbiano difetti, ovviamente. E se un utente malintenzionato riesce a fuggire dal contenitore, non si applica nessuno dei precedenti. Aggiunge un po 'di overhead ma è possibile un approccio a cintura e bretelle: contenitori sopra le VM.