TLDR

  • Una privilege escalation locale non e innocua quando l'ambiente esegue codice non fidato.
  • Container, CI, sandbox per agenti AI e hosting multi-tenant condividono spesso il kernel: se il kernel cade, il confine si assottiglia.
  • GhostLock e altre vulnerabilita recenti riportano al centro patching, isolamento e riduzione dei servizi esposti.
  • Per carichi non fidati, microVM e isolamento piu forte possono ridurre il blast radius rispetto ai container puri.

Perche conta ora

"E solo locale" e una delle frasi piu pericolose della sicurezza.

Locale per chi?

Locale su un laptop personale forse significa che l'attaccante deve gia aver fatto un pezzo di strada. Locale su un runner CI che compila pull request non fidate e un altro film. Locale dentro un container che esegue codice generato da un agente AI e ancora un altro. Locale su hosting multi-tenant puo essere l'inizio di una storia brutta.

Le vulnerabilita di privilege escalation come GhostLock riportano questa differenza al centro. Il bug non va letto solo come "un modo per diventare root". Va letto come stress test dell'isolamento.

Se un processo non fidato diventa root nel suo ambiente, cosa puo toccare davvero?

Il kernel e il confine vero

I container sono comodi, veloci e fondamentali. Ma non sono micro-macchine magiche.

In un container classico, molti meccanismi di isolamento dipendono dallo stesso kernel dell'host: namespace, cgroup, seccomp, capability, filesystem virtuale. Se il kernel ha un bug sfruttabile dal processo, il confine puo diventare piu sottile di quanto sembri nella dashboard.

Questo non significa "i container sono inutili". Significa che bisogna usarli sapendo dove finisce la loro promessa.

Un container puo limitare moltissimo. Ma se stai eseguendo codice ostile, la domanda diventa: ti fidi del kernel condiviso come unico muro?

Dove il rischio cresce

La privilege escalation locale diventa piu seria in questi ambienti:

  • CI/CD che esegue codice da fork o pull request esterne;
  • sandbox per agenti AI e coding assistant;
  • piattaforme multi-tenant;
  • server con container privilegiati;
  • host con filesystem o socket montati nel container;
  • workload che espongono servizi kernel-space o moduli complessi;
  • sistemi non patchati perche "tanto non sono esposti".

Quel "non sono esposti" spesso significa solo "non hanno una porta web pubblica". Ma se accettano job, plugin, file, archivi, script o codice generato, allora una superficie esiste.

Patchare non basta, ma serve

La prima risposta resta noiosa: patchare.

Kernel, distro, container runtime, orchestrator e servizi esposti devono ricevere aggiornamenti. La noia qui e una qualita. Il problema e che la patch chiude una finestra dopo che la vulnerabilita e nota. Non elimina la classe di rischio.

Per questo servono anche:

  • profili seccomp restrittivi;
  • AppArmor o SELinux dove disponibili;
  • niente container privilegiati se non indispensabili;
  • mount read-only quando possibile;
  • nessun socket Docker dentro container non fidati;
  • separazione dei runner CI;
  • rotazione rapida degli host;
  • log di syscall o comportamento anomalo su workload sensibili;
  • isolamento piu forte per codice non fidato.

Ogni controllo deve rispondere a una domanda: se il processo dentro il container vince, quanto lontano arriva?

MicroVM e sandbox AI

L'esplosione degli agenti AI ha rimesso in moda una parola che sembrava roba da infrastruttura: sandbox.

Un agente che scrive ed esegue codice non fidato ha bisogno di un recinto serio. Se quel recinto e un container sul tuo stesso kernel, una LPE cambia significato. Se invece il codice gira in una microVM con kernel guest separato, il percorso verso l'host diventa piu difficile.

Non e invulnerabilita. Hypervisor, VMM e kernel host hanno bug anche loro. Pero cambia il livello del confine.

La differenza pratica e questa:

  • container: veloce, leggero, ottimo per molti workload fidati o semi-fidati;
  • microVM: piu pesante, ma piu sensata per codice ostile, tenant esterni, agenti automatici e runner rischiosi.

La scelta non e religiosa. E threat modeling.

Cosa controllare subito

Su server Linux e ambienti container:

  1. Versione kernel e patch pendenti.
  2. Presenza di servizi kernel-space esposti o poco usati.
  3. Container privilegiati.
  4. Mount di /var/run/docker.sock o directory host sensibili.
  5. Runner CI condivisi tra progetti fidati e non fidati.
  6. Capability troppo larghe.
  7. Profili seccomp disattivati.
  8. Segreti disponibili dentro container di build.
  9. Workload AI che eseguono codice generato.

Se un host fa girare cose non fidate, trattalo come sacrificabile. Ricreabile, osservabile, isolato.

La lezione

Locale non significa piccolo.

In un mondo di container, CI, plugin, estensioni, agenti e sandbox, "locale" puo essere il secondo passo di un attacco remoto. Il primo passo entra da una pull request, un file, un job, una dipendenza, un prompt. Il secondo prova a diventare root.

La difesa non e panico. E architettura.

Sapere quale kernel condividi, con chi lo condividi e cosa succede quando qualcuno lo stressa male.

FAQ

Che cos'e una privilege escalation locale?

E una vulnerabilita che permette a un utente o processo gia presente sul sistema di ottenere privilegi maggiori, spesso fino a root o amministratore.

Perche conta nei container?

Perche i container condividono il kernel dell'host. Se un bug colpisce il kernel, l'isolamento a livello container puo non bastare.

GhostLock e un exploit da copiare?

No. Va trattato come segnale difensivo: patchare, verificare esposizione, controllare servizi e ridurre il codice non fidato che gira sullo stesso kernel.

Le microVM risolvono tutto?

No, ma separano il kernel guest dal kernel host e possono ridurre l'impatto di alcune classi di bug rispetto ai container tradizionali.

Cosa devo controllare su server Linux?

Versione kernel, patch di sicurezza, servizi esposti come SMB, workload non fidati, privilegi dei container, seccomp, AppArmor/SELinux e log di comportamento anomalo.

Fonti