Ограничить функциональность нативного кода из Java

Question

У меня есть Java-приложение, которое использует JNI в некоторых частях для выполнения определенной работы. Это следует за обычной загрузкой DLL и последующим вызовом собственных методов DLL. Есть ли способ, которым мы можем ограничить то, что нативные методы могут делать из Java-приложения? Например, можем ли мы запретить DLL-файлам не открывать какие-либо файлы или не открывать какие-либо сокеты, даже если для этого есть код? Он может просто запретить DLL-файлы, загружаемые им для выполнения определенных действий, например, выполнить вход в систему или выдать исключение.

Answer 1

Нет, ты не можешь. DLL загружается целиком, а затем сторона Java не может контролировать, что делает нативный код.

Одним из решений может быть вид человека со средним подходом. Это будет включать кодирование DLL-оболочки "shell", которая имеет тот же интерфейс, что и исходная DLL. Вы указываете Java загружать DLL-оболочку, например, помещая ее в определенное место и используя свойство java.library.path. Тогда роль «shell» DLL заключается в том, чтобы загрузить «true» DLL, поместив ее в «песочницу» и перенаправив стандартные функции. Это звучит как большая боль, и это происходит на родной стороне, а не на Java.

Answer 2

Мне понравилось Григорий Пакош ' ответ много. Тем не менее, то, что вы могли бы сделать, это песочница сам экземпляр Java. Запустите само приложение Java в ограниченном контексте.

В Windows или Unix вы можете создать пользователя, который ограничен определенным каталогом и имеет доступ только к некоторым DLL. Таким образом, DLL, вызываемая из JNI, может делать все, что захочет, но это не очень далеко, потому что пользователь, которого запускает Java, не может сделать очень многое.

Если вашей Java-программе нужно делать привилегированные вещи, ее стороне на Java придется поговорить с другой программой (Java или нет), чтобы сделать ее «привилегированные вещи для нее».

Просто имейте в виду, что если вы не можете доверять DLL, вы больше не можете доверять Java-коду, поскольку DLL могла "взломать" Java-машину. С другой стороны, никакие неприятные вещи не должны выходить за пределы пользователя, от имени которого они работают. (За исключением неправильной конфигурации или ошибки в ОС.)

Edit 2018: сегодня, возможно, более уместно указать, что песочницей для запуска Java, скорее всего, будет виртуальная машина в облаке Amazon, Docker или что-то еще в заблокированной конфигурации.

Answer 3

Вы можете реализовать какую-то настройку, которую может получить ваш код JNI. Например, в системе UNIX вы можете создать группы для особых типов привилегий и проверить, есть ли у текущего пользователя требуемые привилегии, иначе просто верните 0 или что-то еще.

Answer 4

Обычно вы запускаете свое приложение в Java Security Manager, но я не думаю, что это повлияет на код, выполняемый через JNI.