De comprobaciones de SecurityManager a autorización explícita
Sustituye las comprobaciones deshabilitadas de SecurityManager por autorización explícita en la aplicación y aislamiento en el despliegue.
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);
Política explícita
La autorización es visible y comprobable en la lógica de la aplicación.
Aislamiento real
Los límites de proceso, contenedor y sistema operativo protegen toda la aplicación.
Migración obligatoria
Elimina comprobaciones que ya no pueden aplicar políticas en JDK 24 y versiones posteriores.
Obligatorio en JDK 24 y versiones posteriores, donde JEP 486 deshabilita permanentemente el Security Manager.
JEP 486 deshabilitó permanentemente el Security Manager en JDK 24, por lo que las comprobaciones mediante System.getSecurityManager() solo pueden aplicar políticas en JDK 23 y versiones anteriores. Las aplicaciones deben autorizar el acceso explícitamente en la lógica de dominio; resolver las rutas reales del sistema de archivos evita que los enlaces simbólicos existentes escapen de una raíz permitida cuando los usuarios no confiables no pueden modificar ese árbol simultáneamente. En árboles donde un atacante pueda escribir, utiliza acceso relativo a identificadores y resistente a condiciones de carrera, como SecureDirectoryStream. Utiliza límites de proceso, contenedor o sistema operativo para el aislamiento. JDK 24 conserva temporalmente la API obsoleta, pero no se puede habilitar ni ha sido sustituida por otro entorno aislado dentro del proceso.