Модель безопасности Java ClassLoader - PullRequest
7 голосов
/ 11 марта 2012

Я пытаюсь понять модель безопасности, используемую, когда JVM просят загрузить классы.

Из спецификации JVM для песочницы я уверен, что стандартная реализация JVM должна поддерживать как минимум еще одну ClassLoader, независимую от primordial ClassLoader. Это используется для загрузки файлов классов приложения (например, из предоставленного пути к классам).

Если класс запрашивается из ClassLoader, который не находится в его пространстве имен, например java/lang/String, то он перенаправляет запрос в изначальный ClassLoader, который пытается загрузить класс из API Java, если его нет, тогда он бросает NoClassDefFoundError.

Прав ли я, полагая, что изначальный ClassLoader загружает только классы из пространства имен Java API, а все другие классы загружаются через отдельную реализацию ClassLoader?

И это делает загрузку классов более безопасной, потому что это означает, что вредоносный класс не может маскироваться как член Java API (скажем, java/lang/Virus), потому что это защищенное пространство имен и не может использоваться в текущем ClassLoader

Но есть ли что-то, чтобы предотвратить замену Классов Java API на вредоносные классы, или это будет обнаружено во время class проверки?

1 Ответ

7 голосов
/ 12 марта 2012

По историческим причинам имена, используемые для загрузчиков классов, немного странны.Загрузчик загрузочных классов загружает системные классы.Системный загрузчик классов по умолчанию загружает классы из пути к классам, а не из системных классов.Системные классы находятся в jre / lib (в основном в rt.jar), одобренных каталогах и где угодно добавляются через -Xbootclasspath.

В Sun / Oracle JRE rt.jar содержит классы с пакетами, начинающимися с java., javax., sun., com.sun., org.omg, org.w3c и org.xml.

Ненадежный код (включая конфигурацию) не должен быть в состоянии добавить в системные классы.Некоторые имена пакетов с префиксом могут быть ограничены с помощью свойства безопасности.ЯваПрефикс специально защищен от не по техническим причинам.

Обычно загрузчик классов делегирует своему родителю до определения нового класса, предотвращая замену любых классов из загрузчика предка.Java EE рекомендует (несмотря на запреты Java SE), чтобы некоторые загрузчики классов предпочитали свои собственные классы, как правило, чтобы использовать более современный API или другую реализацию.Это позволяет скрывать классы, но только в том виде, в каком они видны через этот загрузчик (и его дочерние элементы).Все остальные классы продолжают ссылаться на оригинал.

...