Il confine che conta: perché userland e kernel non sono la stessa cosa
A metà luglio la scena PS5 ha reso pubblico Y2JB: un’esecuzione di codice arbitrario ottenuta sfruttando una falla nell’app YouTube della console. Nessun jailbreak completo, nessun accesso al kernel. Solo, per usare un’immagine semplice, un grimaldello che apre il cancello del cortile senza toccare la porta blindata di casa.
È un buon punto di partenza per parlare di una cosa che in classe ripeto spesso, perché è uno dei concetti che separa chi “usa” un sistema operativo da chi lo capisce davvero: la separazione dei privilegi.
Userland vs kernel: due mondi, un solo processore
Ogni sistema operativo moderno, che sia il firmware di una console o il kernel Linux su un server, disegna un confine netto tra due mondi. Da una parte lo userland: i processi applicativi, con accesso limitato alla memoria, alle periferiche, al filesystem. Dall’altra il kernel: l’unico strato con accesso diretto all’hardware, alla gestione della memoria fisica, ai driver, alle system call che tutto il resto del sistema deve necessariamente attraversare.
Un’app come YouTube su PS5 vive interamente in userland, sandboxata, con permessi ridotti all’osso. Quando qualcuno trova un bug nel parser JavaScript o nella gestione della memoria di quell’app e riesce a eseguire codice proprio, ottiene comunque solo i privilegi di quell’app: niente di più. Per arrivare a un vero jailbreak, quello che permette di eseguire codice non firmato a livello di sistema, serve un secondo passaggio, distinto e più difficile: un kernel exploit, che sfrutti una vulnerabilità nel kernel stesso o in un driver privilegiato per scavalcare quel confine.
Questo è esattamente il motivo per cui, tecnicamente, Y2JB non è “il jailbreak della PS5”, per quanto i titoli abbiano semplificato. È il primo anello di una catena che, da solo, non porta da nessuna parte.
Perché il confine tra userland e kernel è il vero perimetro difensivo
La cosa interessante, dal punto di vista di chi progetta sistemi sicuri, non è tanto se un bug in userland esista (esisterà sempre: più codice, più superficie d’attacco), ma quanto sia costoso attraversare il confine successivo. È il principio della difesa in profondità: non un solo muro, ma una sequenza di muri indipendenti, ciascuno pensato per reggere anche se quello prima ha ceduto.
Lo stesso schema si ripete, con posta in gioco molto più alta, nell’infrastruttura enterprise. Prendiamo la breach recente ai danni di Accenture, con furto rivendicato di codice sorgente, chiavi SSH e token di accesso Azure: anche lì, l’attaccante è quasi certamente entrato da un punto periferico (una credenziale, un servizio esposto, un endpoint mal configurato) e ha dovuto muoversi lateralmente, scalare privilegi, attraversare confini pensati apposta per fermarlo. La differenza tra un incidente contenuto e un disastro completo si misura esattamente lì: in quanti confini reggono e quanti no.
Il vettore che cambia: dall’exploit al prompt
C’è però una variabile nuova che vale la pena notare. I primi attacchi documentati di prompt injection usati come vettore di comando e controllo contro assistenti AI, insieme alla scoperta di migliaia di server MCP esposti in rete senza autenticazione, raccontano uno spostamento interessante: il “codice” che attraversa un confine di privilegio non è più necessariamente scritto in C o Assembly. Può essere una frase scritta in linguaggio naturale, infilata in un documento, in un’email, in una pagina web che un agente AI leggerà e tratterà come istruzione.
Il principio di fondo non cambia: qualunque superficie che accetta input strutturato è un potenziale punto di ingresso. Cambia però la barriera all’ingresso per chi lo sfrutta, ed è una barriera che si sta abbassando rapidamente.
Perché conoscere questo confine non è roba da specialisti
Non serve fare pentest di mestiere per avere bisogno di questo tipo di comprensione. Capire cosa separa uno userland da un kernel, cosa significa realmente “privilegio” in un sistema operativo, come funzionano permessi, processi e system call, è la base logica su cui si costruisce qualunque ragionamento serio sulla sicurezza, sia che si stia proteggendo un server, sia che si stia solo cercando di capire perché una console con un budget di sicurezza a nove zeri può comunque essere aggirata da un bug in un’app di streaming.
È esattamente il tipo di fondamenta che ho provato a costruire in Linux Lab, partendo da zero e arrivando fino ai meccanismi che governano processi, filesystem e rete. Se questi temi vi incuriosiscono, la pagina del progetto racconta il percorso completo, dal primo volume dedicato alla sopravvivenza nel terminale al secondo, che entra nel dettaglio di pacchetti, rotte e verità di rete.
