Dai controlli SecurityManager all’autorizzazione esplicita
Sostituisci i controlli SecurityManager disabilitati con l’autorizzazione esplicita dell’applicazione e l’isolamento del deployment.
SecurityManager manager = System.getSecurityManager();
if (manager != null) {
manager.checkRead(path.toString());
}
return Files.readString(path);
// Untrusted users must not be able to modify this tree
Path root = allowedRoot.toRealPath();
Path resolved = root.resolve(requested)
.normalize()
.toRealPath();
if (!resolved.startsWith(root)) {
throw new SecurityException(
"Path is outside the allowed root");
}
return Files.readString(resolved);
Policy esplicita
L’autorizzazione è visibile e verificabile nella logica dell’applicazione.
Isolamento reale
I confini di processo, container e sistema operativo proteggono l’intera applicazione.
Migrazione obbligatoria
Rimuove i controlli che non possono più applicare policy su JDK 24 e versioni successive.
Obbligatoria su JDK 24 e versioni successive, dove JEP 486 disabilita definitivamente il Security Manager.
JEP 486 ha disabilitato definitivamente il Security Manager in JDK 24, quindi i controlli tramite System.getSecurityManager() possono applicare policy solo su JDK 23 e versioni precedenti. Le applicazioni devono autorizzare esplicitamente l’accesso nella logica di dominio; la risoluzione dei percorsi reali del file system impedisce ai collegamenti simbolici esistenti di uscire da una directory radice consentita quando gli utenti non attendibili non possono modificare simultaneamente tale albero. Per gli alberi scrivibili da un attaccante, usa un accesso relativo agli handle e resistente alle race condition, come SecureDirectoryStream. Usa i confini di processo, container o sistema operativo per l’isolamento. JDK 24 conserva temporaneamente l’API deprecata, ma non è possibile abilitarla e non è stata sostituita da un’altra sandbox interna al processo.