Od kontroli SecurityManager do jawnej autoryzacji
Zastąp wyłączone kontrole SecurityManager jawną autoryzacją w aplikacji i izolacją środowiska wdrożeniowego.
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);
Jawne zasady
Autoryzacja jest widoczna i możliwa do przetestowania w logice aplikacji.
Rzeczywista izolacja
Granice procesów, kontenerów i systemu operacyjnego chronią całą aplikację.
Wymagana migracja
Usuwa kontrole, które nie mogą już egzekwować zasad w JDK 24 i nowszych wersjach.
Wymagane w JDK 24 i nowszych wersjach, w których JEP 486 trwale wyłącza Security Manager.
JEP 486 trwale wyłączył Security Manager w JDK 24, dlatego kontrole za pośrednictwem System.getSecurityManager() mogą egzekwować zasady tylko w JDK 23 i starszych wersjach. Aplikacje muszą jawnie autoryzować dostęp w logice domenowej; rozwiązywanie rzeczywistych ścieżek systemu plików zapobiega wydostawaniu się istniejących dowiązań symbolicznych poza dozwolony katalog główny, gdy niezaufani użytkownicy nie mogą jednocześnie modyfikować tego drzewa. W przypadku drzew zapisywalnych przez atakującego użyj odpornego na wyścigi dostępu względnego względem uchwytu, takiego jak SecureDirectoryStream. Do izolacji używaj granic procesów, kontenerów lub systemu operacyjnego. JDK 24 tymczasowo zachowuje przestarzałe API, ale nie można go włączyć i nie zastąpiono go inną piaskownicą działającą wewnątrz procesu.