Отключить отражение Java для текущего потока

Question

Мне нужно вызвать некоторый полунадежный Java-код и вы хотите отключить возможность использования отражения на протяжении всего выполнения этого кода.

try{ 
    // disable reflection somehow 
    someObject.method(); 
} 
finally{ 
    // enable reflection again 
} 

Можно ли это сделать с помощью SecurityManager, и если да, то каким образом?

Разъяснение/Контекст: Это последующая деятельность по сравнению с another question об ограничении пакетов, которые могут быть вызваны из JavaScript/Rhino. Принятый ответ ссылается на запись в блоге о том, как это сделать, и для этого требуется два шага, первый из которых использует Rhino API (ClassShutter), второй - отключение отражения и Class.forName(). Я думал, что могу сделать этот второй шаг более чисто, используя SecurityManager (узнав о SecurityManager, который, как было указано, является сложным зверьком, на этом пути).

Чтобы подвести итог, я хочу (из кода, а не установочного файла) отключить Class.forName() и любой доступ ко всему пакету отражения.

Answer 1

Это зависит от того, что вы пытаетесь ограничить.

В общем, общедоступный API не ограничен. Однако до тех пор, пока вы не предоставите ненадежный код ReflectPermission("suppressAccessChecks"), он не сможет получить доступ к непубличному API в другом пакете.

Если у вас есть список пакетов, к которым вы хотите ограничить доступ, существует два шага. Во-первых, в свойствах Security, include the restricted package in the package.access list. Затем дайте доверенным код RuntimePermission("accessClassInPackage." + pkg).

Обычный способ отличить ваш ненадежный код - загрузить его из другого места и ссылаться на различные кодовые базы в файле политики при предоставлении разрешений.

Архитектура безопасности Java очень мощная, но я знаю, что она также сложна; если вы хотите более конкретный пример, пожалуйста, опишите, какие именно вызовы вы хотите ограничить, и я попытаюсь быть более явным.

---

Чтобы сделать то, что вы хотите без изменения файла java.policy и/или файл java.security будет очень трудно, может быть невозможно. java.security.Policy представляет информацию в java.policy, но не предлагает доступ на запись. Вы можете создать свою собственную реализацию Policy и установить ее во время выполнения, если это разрешит любой существующий SecurityManager.

С другой стороны, вы можете указать пользовательский файл java.policy в качестве параметра командной строки. Если вы предоставляете полное приложение с помощью своего рода пусковой установки, это может быть легко выполнено. Он также обеспечивает определенную прозрачность для ваших пользователей. Изощренный пользователь может просмотреть разрешения, которые вы хотели бы предоставить приложению.

Answer 2

Ну, вы можете переопределить SecurityManager.checkMemberAccess и дать более точное определение. Однако на самом деле это не так. Что происходит, например, если код определяет финализатор?

Об уточнении: Другие API-интерфейсы используют отражение и другие API-интерфейсы. Например, java.beans, LiveConnect и Rhino. Противник может из сценария, скажем, создать новый контекст Rhino без затвора и, таким образом, загрузиться в полную JRE. С открытой системой черный список никогда не может быть завершен.

Таким образом: для использования модели безопасности Java вам необходимо работать с ней, а не против нее.

Answer 3

Я написал замену ClassShutter, что позволяет мелкозернистой контроля доступа, в частности, по методу, в поле:

http://riven8192.blogspot.com/2010/07/java-rhino-fine-grained-classshutter.html