От проверок SecurityManager к явной авторизации
Замените отключённые проверки SecurityManager явной авторизацией в приложении и изоляцией на уровне развёртывания.
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);
Явная политика
Авторизация видна и поддаётся тестированию в логике приложения.
Настоящая изоляция
Границы процессов, контейнеров и операционной системы защищают всё приложение.
Обязательная миграция
Удаляет проверки, которые больше не могут обеспечивать соблюдение политик в JDK 24 и более поздних версиях.
Обязательно для JDK 24 и более поздних версий, где JEP 486 окончательно отключает Security Manager.
JEP 486 окончательно отключил Security Manager в JDK 24, поэтому проверки через System.getSecurityManager() могут обеспечивать соблюдение политик только в JDK 23 и более ранних версиях. Приложения должны явно авторизовать доступ в доменной логике; разрешение реальных путей файловой системы не позволяет существующим символическим ссылкам выйти за пределы разрешённого корневого каталога, если недоверенные пользователи не могут одновременно изменять это дерево. Для деревьев, доступных злоумышленнику на запись, используйте устойчивый к состояниям гонки доступ относительно дескриптора, например SecureDirectoryStream. Для изоляции используйте границы процессов, контейнеров или операционной системы. JDK 24 временно сохраняет устаревший API, однако его нельзя включить и он не заменён другой внутрипроцессной песочницей.