Добавление защиты сценариев в приложение

Question

Допустим, у меня есть приложение, написанное на Java, в которое я хочу добавить поддержку сценариев. Это довольно тривиально с Groovy (и точно так же тривиально в .Net с любым из динамических языков Iron).

Несмотря на то, что добавление поддержки тривиально, возникает целый ряд вопросов о выполнении сценариев и безопасности - и о том, как реализовать эту защиту.

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

Быстрое редактирование

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

Например, как разработчик / поставщик приложения, я распространяю подписанный скрипт. Этот сценарий законно «разрушает данные» по своему замыслу. Такой как его природа, он должен выполняться только администраторами, и поэтому подавляющее большинство пользователей / системных процессов не должно быть в состоянии запустить его. В таком случае мне кажется, что необходим какой-то контекст безопасности / аутентификации, основанный на действиях, которые выполняет скрипт и кто запускает этот скрипт.

Answer 1

сценарий подписи

Концептуально, это просто проникновение в ваш набор инструментов криптографии и использование существующих инструментов. Попросите людей подписать свой код, проверить подписи при загрузке и проверить, что создатель подписи заслуживает доверия.

Сложный вопрос - что делает людей достойными доверия и кто их выбирает. Если ваши пользователи не являются техническими специалистами, они не хотят думать об этом, и поэтому они не будут устанавливать хорошую политику. С другой стороны, вы, вероятно, будете иметь , чтобы позволить пользователям ввести доверие [если только вы не захотите пойти в огороженный сад в стиле iPhone AppStore, на что это не похоже].

аутентификация скрипта

Чем это отличается от подписания? Или это ваш вопрос: «о каких концепциях я должен думать здесь?»

Реальный вопрос, конечно же: от чего вы хотите защитить своих пользователей? Это только транзитная модификация, или вы также хотите дать гарантии о поведении сценариев? Вот некоторые примеры: сценарии не могут получить доступ к файловой системе, сценарии могут получить доступ только к определенному поддереву файловой системы, сценарии не могут получить доступ к сети и т. Д.

Я думаю, что было бы возможно [при скромном объеме работы] обеспечить некоторые гарантии того, как скрипты получают доступ к внешнему миру, если они были сделаны в haskell, и монада IO была разбита на более мелкие части. Или, возможно, если у вас были скрипты, запущенные в собственной непрозрачной монаде с доступом к ограниченной части ввода-вывода. Обязательно удалите доступ к небезопасным функциям.

Возможно, вы также захотите взглянуть на соображения, которые вошли в модель безопасности Java (апплет).

Надеюсь, это заставит вас задуматься.

Answer 2

Вы можете взглянуть на документацию по безопасности: http://groovy.codehaus.org/Security По сути, вы можете использовать обычный менеджер безопасности Java.

И кроме этого, есть пример приложения, показывающего, как вы можете анализировать код путем анализа его AST (абстрактного синтаксического дерева) во время компиляции, чтобы вы могли разрешить / запретить определенные конструкции кода и т. Д. Вот пример арифметическая оболочка, показывающая это в действии: http://svn.groovy.codehaus.org/browse/groovy/trunk/groovy/groovy-core/src/examples/groovyShell