Безопасность с помощью сценариев Java (JRuby, Jython, Groovy, BeanShell и т. Д.)

Question

Я хочу запустить несколько неподтвержденных сценариев (написанных на языке, который еще не определен, но должен быть основан на Java, поэтому кандидатами являются JRuby, Groovy, Jython, BeanShell и т. Д.). Я хочу, чтобы эти сценарии могли выполнять какие-то действия и были ограничены в выполнении других.

Обычно, я бы просто использовал Java SecurityManager и покончил с этим. Это довольно просто и позволяет мне ограничить доступ к файлам и сети, возможность выключения JVM и т. Д. И это будет хорошо работать для высокоуровневых вещей, которые я хочу заблокировать.

Но есть кое-что, что я хочу разрешить, но только через мой собственный API / библиотеку, которую я предоставляю. Например, я не хочу разрешать прямой доступ к сети, чтобы открыть URLConnection для yahoo.com, но я в порядке, если это сделано с MyURLConnection. То есть - есть набор методов / классов, которые я хочу разрешить, а затем все остальное, что я хочу запретить.

Я не верю, что этот тип безопасности может быть реализован с помощью стандартной модели безопасности Java, но, возможно, это возможно. У меня нет особых требований к производительности или гибкости в самом языке сценариев (сценарии будут простыми процедурными вызовами моего API с базовыми циклами / ветвлениями). Так что даже "большие" издержки, которые проверяют проверку безопасности при каждом вызове отражения, меня устраивают.

Предложения

Answer 1

Отказ от ответственности: я не эксперт по API безопасности Java, поэтому может быть лучший способ сделать это.

Я работаю для Alfresco , CMS на базе Java с открытым исходным кодом, и мы реализовали нечто похожее на то, что вы описываете. Мы хотели разрешить создание сценариев, но только для предоставления подсистемы сценариев подмножества наших Java API.

Мы выбрали Rhino Engine для сценариев JavaScript. Это позволяет вам контролировать, какие API доступны JavaScript, что позволяет нам выбирать, какие классы доступны, а какие нет. Накладные расходы, по мнению наших инженеров, составляют порядка 10% - неплохо.

В дополнение к этому, и это может иметь отношение и к вам, на стороне Java мы используем Acegi (теперь Spring Security) и используем AOP, чтобы предоставить контроль над ролями над тем, какие методы может вызывать определенный пользователь. Это очень хорошо работает для авторизации. Таким образом, по сути, пользователь, получающий доступ к нашему приложению через JavaScript, сначала имеет доступ к ограниченному API, а затем этот API может быть еще более ограничен на основе авторизации. Таким образом, вы можете использовать методы AOP для дальнейшего ограничения того, какие методы можно вызывать, что позволяет раскрыть это на других языках сценариев, таких как Groovy и т. Д. Мы также добавляем их, имея уверенность в том, что наша базовая Java API защищают пользователей от несанкционированного доступа.

Answer 2

Вы можете использовать пользовательский загрузчик классов, который проверяет ссылки на классы перед делегированием его родителю.

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

Вы должны убедиться, что сам скрипт-движок безопасен. Версия Rhino in the Sun JDK должна быть в порядке, но никаких гарантий. Очевидно, вам нужно убедиться, что все доступное для скрипта безопасно.

Answer 3

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

http://www.chrismoos.com/2010/03/24/groovy-scripts-and-jvm-security/