Запуск .NET-процесса в AppDomain

Название моего вопроса может уже дать тот факт, что я не уверен в том, чего хочу, поскольку это может и не иметь смысла.Запуск .NET-процесса в AppDomain

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

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

Я читал в разных местах в Интернете, что эти разрешения могут быть установлены с помощью PermissionStates при создании AppDomain, в котором вы можете выполнить исполняемые файлы. Тем не менее, я не нашел способ связаться с исполняемыми файлами через их стандарт в и из, что очень важно. Однако я могу это сделать при запуске нового процесса (Process.Start()), хотя тогда я не могу установить границы того, что разрешено исполняемому файлу.

Моя интуиция подсказывает мне, что я должен каким-то образом выполнить процесс внутри AppDomain, так что процесс «запускает» в домене, хотя я не вижу способа сделать это прямо.

Мой коллега выполнил это, создав прокси-приложение, которое в основном является другим исполняемым файлом, в котором создается AppDomain, в котором выполняется фактический исполняемый файл. Затем прокси-приложение запускается процессом в основном приложении. Я думаю, что это крутая идея, хотя я чувствую, что мне не нужен этот шаг.

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

источник

2016-12-02 Glubus

Это чрезвычайно сложно, к сожалению, есть причина, по которой эти подходы к безопасности терпят неудачу снова и снова, они огромные усилия, и никто не понимает их правильно. Однако то, что вы можете сделать, - это запустить процесс как ограниченный пользователь, - хотя он не дает вам детализации, которую дает CAS, это также намного проще и обеспечивает изоляцию процесса.In-process extensions может очень легко убить ваше приложение :) – Luaan

Невозможно запустить процесс в «AppDomain», потому что это совершенно разные концепции. 'Процесс AppDomain запускается в процессах, а не наоборот. И, конечно же, они работают только для приложений .NET: – Luaan

@ Luaan, тогда что происходит, когда я вызываю 'AppDomain.Create (...). ExecuteAssembly (pathToMyStuff)'? Мне кажется, что это начинает новый процесс, но, согласно вашему утверждению, это не так ... – Glubus

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

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

применение прокси затем настроить ограниченный AppDomain и выполнить песочницу код, подобный подход, описанный здесь:

How to: Run Partially Trusted Code in a Sandbox

Кроме того, вы можете использовать mechansims уровня операционной системы, чтобы уменьшить поверхность атаки процесса. Это может быть достигнуто, например, путем запуска прокси-процесса с наименьшей целостностью, которая удаляет доступ на запись к большинству ресурсов (например, разрешить запись файлов только в AppData \ LocalLow). См., Например, here.

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

источник

2016-12-02 10:42:54

Я думаю, я не совсем понимаю, что делает AppDomain, когда он вызывает ExecuteAssembly(), мне кажется, что он запускает еще один процесс , хотя, видимо, если я общаюсь с прокси-приложением, я фактически говорю с исполняемым файлом, с которым хочу поговорить, поскольку он загружен в прокси-приложении через созданный appdomain. – Glubus

@Glubus: 'ExecuteAssembly' не запускает новый процесс, а выполняет в AppDomain в том же процессе. Поэтому связь работает, если вы общаетесь с «прокси» -приложением. –

Итак, вы говорите, что Console.WriteLine() в прокси-приложении записывает в тот же поток при вызове в исполняемой сборке при запуске в AppDomain? Кажется, наполовину очевидным для меня сейчас, прочитав ваши комментарии и комментарии Luaans. – Glubus

ответ

Смежные вопросы