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

Question

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

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

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

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

Предложения?

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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