Запуск приложения .Net в песочнице

За несколько месяцев я разработал персональный инструмент, который использую для компиляции проектов C# 3.5 Xaml в режиме онлайн. По сути, я компилирую компилятором CodeDom. Я подумываю о том, чтобы опубликовать его, но проблема в том, что с помощью этого инструмента очень-очень легко делать что-либо на сервере.

Причина, по которой я хочу защитить свой сервер, заключается в том, что есть кнопка «Выполнить» для тестирования и отладки приложения (в режиме скриншота).

Возможно ли запустить приложение в песочнице, другими словами, ограничить доступ к памяти, доступ к жесткому диску и доступ к BIOS, не запуская его на виртуальной машине? Или я должен просто проанализировать каждый код или «отключить» режим «Выполнить»?


.net c# sandbox
person Léon Pelletier    schedule 05.03.2013    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Раскрутите AppDomain, загрузите в него сборки, найдите интерфейс, которым вы управляете, активируйте реализующий тип, вызовите свой метод. Просто не позволяйте никаким экземплярам пересекать этот барьер AppDomain (включая исключения!), которые вы не контролируете на 100%.

Управление политиками безопасности для вашего AppDomain с внешним кодом — это слишком много для одного ответа, но вы можете проверьте эту ссылку в MSDN или просто выполните поиск по запросу "безопасность доступа к коду msdn", чтобы получить сведения о том, как защитить этот домен.

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

Кроме того, всегда лучше внедрить в этот второй AppDomain тип, который затем будет использоваться для загрузки и выполнения всех операций. Таким образом, вы гарантируете, что ни один тип (который не приведет к остановке всего вашего приложения) не пересечет границы AppDomain. Я обнаружил, что полезно определить тип, расширяющий MarshalByRefObject, для которого вы вызываете методы, выполняющие небезопасный код во втором AppDomain. Он никогда не должен возвращать незапечатанный тип, который не помечен как Сериализуемый за границей, ни в качестве параметра метода, ни в качестве возвращаемого типа. Пока вы можете достичь этого, вы прошли 90% пути.

person Community    schedule 05.03.2013
comment
Это предназначено для веб-приложения или для любого клиентского кода .Net? - person Léon Pelletier; 05.03.2013
comment
@LéonPelletier оба. Вы можете раскрутить AppDomain в любом месте и в любое время. Однако вы не можете сделать это в течение одного ответа в любом приложении (в частности, в браузере и на рабочем столе). Итак, у вас есть (если вы хотите, чтобы ваш пользовательский интерфейс был отзывчивым) сделать это в другом потоке. Немного сложнее в веб-приложении, но выполнимо. Вам просто нужно опросить веб-сайт асинхронно, а затем перенаправить, когда закончите. - person ; 05.03.2013
comment
+1. @LéonPelletier - любой код .Net. Обратите внимание, что даже самая строгая политика CAS и проверка кода не защищают вас полностью — проще всего создать StackOverflowException с некоторым рекурсивным вызовом для разрыва домена/процесса приложения — требуется только минимально возможный набор разрешений (выполнение). - person Alexei Levenkov; 05.03.2013
comment
@AlexeiLevenkov определенно есть исключения, которые нельзя перехватить или обработать. Таких немного и далеко друг от друга, но вы всегда можете записать их, изящно восстановиться и воздержаться от повторной загрузки наступательных сборок. Конечно, в веб-приложении это важнее, чем на десктопе. - person ; 05.03.2013
comment
Поскольку это платформа для разработки, обычная программа должна записывать пользовательские или конфигурационные данные, поэтому кажется, что мне лучше управлять ею с помощью виртуальных машин и больше заботиться о ЦП и разрешениях. - person Léon Pelletier; 05.03.2013
comment
@LéonPelletier, это кажется тяжелым бременем. Но тот, который гарантирует изоляцию через машины. В этом случае вам нужно беспокоиться только о доступе к общим ресурсам (диск, сеть и т. д.). - person ; 05.03.2013