Container VS Macchine Virtuali: qual'è la soluzione più sicura?

Il settore dei container ha rivoluzionato il modo di sviluppare e distribuire software, andando spesso a sostituire le macchine virtuali in alcuni settori. Ma quale dei due sistemi è il più sicuro? I ricercatori di IBM hanno sviluppato un innovativo sistema per misurare la software security chiamato Horizontal Attack Profile (HAP). Dalle analisi è emerso che un container può essere sicuro quanto, o anche di più, una macchina virtuale.

Di base un contesto virtualizzato, e dunque separato nettamente dall'ambiente host, potrebbe essere considerato nettamente più sicuro di un container che, anche se isolato, condivide con l'host molti più elementi rispetto alle macchine virtuali. James Bottomley, Distinguished Engineer per IBM e Linux kernel developer, afferma che:

"Uno dei maggiori problemi con l'attuale dibattito sulla sicurezza di Container vs Hypervisor è che nessuno ha in realtà sviluppato un modo per misurare il grado di sicurezza [dei due sistemi], quindi il discorso è tutto in termini qualitativi (ovvero si ha la sensazione che gli hypervisor siano più sicuri dei container a causa dell'interfaccia estesa) e nessuno ha effettivamente effettuato un confronto quantitativo."

Dunque per eseguire un'analisi quantitativa il team di IBM ha sviluppato Horizontal Attack Profile, cosi da poter descrivere la system security in modo oggettivo. Sfruttando HAP il team diretto da Bottomley ha scoperto che un'immagine Docker può offrire la medesima sicurezza di un sistema hypervisor, visto che è anche possibile bloccare le chiamate di sistema direttamente dal seccomp profile.

L'HAP è rappresentato da falle di sicurezza dello stack software, che possono essere sfruttate per passare dal sistema host alla macchina virtuale, permettendo quindi di accedere ai file al suo interno. Dunque come è possibile misurare oggettivamente la quantità di HAP? Bottomley ha elaborato un metodo molto preciso.

Bisogna prendere la densità dei bug del codice del kernel Linux e moltiplicarla per la quantità di codice univoco eseguito dal sistema che si trova in uno steady state (ovvero senza che avvenga il trigger di nuove kernel patch). Assumiamo inoltre che la densità dei bug sia uniforme, quindi l'HAP è l'approssimazione della quantità di codice eseguita durante lo steady state.

Il kernel Linux ha un meccanismo che rende possibile misurare tutto ciò, ovvero l'ftrace utilizzabile per tenere traccia di tutte le funzioni chiamate da un dato processo userspace, quindi può fornire l'approssimazione del numero di linee di codice eseguite. Tale metodologia di analisi funzioni sia per i container, dove il codice da analizzare ha origine da un gruppo di processi ben determinato, che per i sistemi hypervisor dove, oltre all'interfaccia diretta dell'hypercall, è necessario aggiungere un controllo per i vari deamon backend, come i thread del kernel di kvm vhost.

In breve più linee di codice sono eseguite, maggiore è la possibilità di avere delle falle di sicurezza HAP. Dunque dopo aver definito come misurare tale falle Bottomley ha iniziato a dare in pasto i dati raccolti a vari tool di benchmark come redis-bench-set, redis-bench-get, python-tornado e node-express. Inoltre tali test sono stati effettuati anche con immagini Docker, Google gVisor, gVisor-kvm, Linux built-in VM hypervisor, Kata Containers e Nabla.

Dopo svariati test Bottomley ha notato che Nablia, il sistema di container di IBM, aveva dei risultati HAP migliori rispetto al classico hypervisor con tecnologia Kata, dunque l'azienda ha realizzato un sistema di container migliore e più sicuro rispetto alle macchine virtuali. Caso contrario invece è ad esempio GVisor, che ottiene risultati abbastanza peggiori, Bottomley ipotizza che il motivo di questo esito stia nella volontà dei programmatori Google di migliorare le performance del container riscrivendo parte dell'interfaccia di chiamata di sistema Linux utilizzando Go, tuttavia nessuno si è preso la briga di verificare quante di queste chiamate di sistema vengano effettivamente utilizzate dal Go runtime.

Secondo Bottomley è possibile ottenere container che sono più sicuri di un sistema hypervisor. Ma il lavoro dei ricercatori non è ancora finito, Il prossimo passo è iniziare a stabilire quale sia il grado di esposizione del codice alle applicazioni malevole, per farò ciò sarebbe necessario sfruttare qualche forma di fuzz testing. I risultati ottenuti da Bottomley infatti sono una base di partenza, l'obbiettivo del developer è migliorare costantemente l'HAP e i metodi di valutazione della sicurezza dei sistemi di sviluppo.

Via James Bottomley