TLDR

  • Una privilege escalation locale non è 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 vulnerabilità recenti riportano al centro patching, isolamento e riduzione dei servizi esposti.
  • Per carichi non fidati, microVM e isolamento più forte possono ridurre il blast radius rispetto ai container puri.

Perché conta ora

"È solo locale" è una delle frasi più pericolose della sicurezza.

Locale per chi?

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

Le vulnerabilità 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 può toccare davvero?

Il kernel è 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 può diventare più 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 può 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 più 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 perché "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 è una qualità. Il problema è che la patch chiude una finestra dopo che la vulnerabilità è 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 più 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 è 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 più difficile.

Non è invulnerabilità. Hypervisor, VMM e kernel host hanno bug anche loro. Però cambia il livello del confine.

La differenza pratica è questa:

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

La scelta non è religiosa. È 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" può 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 è panico. È architettura.

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

FAQ

Che cos’è una privilege escalation locale?

È una vulnerabilità che permette a un utente o processo già presente sul sistema di ottenere privilegi maggiori, spesso fino a root o amministratore.

Perché conta nei container?

Perché i container condividono il kernel dell'host. Se un bug colpisce il kernel, l'isolamento a livello container può non bastare.

GhostLock è 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