Von SecurityManager-Prüfungen zu expliziter Autorisierung
Deaktivierte SecurityManager-Prüfungen durch explizite Anwendungsautorisierung und Isolierung bei der Bereitstellung ersetzen.
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);
Explizite Richtlinie
Die Autorisierung ist in der Anwendungslogik sichtbar und testbar.
Echte Isolierung
Prozess-, Container- und Betriebssystemgrenzen schützen die gesamte Anwendung.
Erforderliche Migration
Entfernt Prüfungen, die unter JDK 24 und neuer keine Richtlinien mehr durchsetzen können.
Erforderlich unter JDK 24 und neuer, wo JEP 486 den Security Manager dauerhaft deaktiviert.
JEP 486 hat den Security Manager in JDK 24 dauerhaft deaktiviert. Daher können Prüfungen über System.getSecurityManager() nur unter JDK 23 und älter Richtlinien durchsetzen. Anwendungen müssen den Zugriff explizit in der Domänenlogik autorisieren; das Auflösen tatsächlicher Dateisystempfade verhindert, dass vorhandene symbolische Links aus einem zulässigen Stammverzeichnis ausbrechen, sofern nicht vertrauenswürdige Benutzer diesen Verzeichnisbaum nicht gleichzeitig verändern können. Für Verzeichnisbäume, in die Angreifer schreiben können, empfiehlt sich ein gegen Race Conditions geschützter, handle-relativer Zugriff wie SecureDirectoryStream. Zur Isolierung sollten Prozess-, Container- oder Betriebssystemgrenzen genutzt werden. JDK 24 behält die veraltete API vorübergehend bei, sie kann jedoch nicht aktiviert werden und wird nicht durch eine andere prozessinterne Sandbox ersetzt.