Как ограничить действия подгружаемой сборки?

Question

[Руслан]

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

Comments

[Василий Банников]

Первое что в голову приходит - проверять через mono Cecil, но кажется есть что-то про лучше

Answer 1

[Василий Банников]

Вариант 1 (для олдов):
Если используется .net Framework, то можно воспользоваться стандартной штукой - AppDomain.
Просто создаёшь для этой недоверенной сборки новый AppDomain с ограниченными правами.
Примеры тут: https://stackoverflow.com/questions/1357231/restri...
На .NET Core, 5 и 6 такое работать не будет, тк в них нет AppDomain.

Вариант 2 (просто не загружаем опасные штуки):
При помощи mono cecil можно проверить, какие методы вызываются в какой-то сторонней сборке, и просто не загружать её, если она использует что-то нелегальное (ну или заменить эти вызовы на что-то своё):
https://github.com/jbevain/cecil
Естественно, надо ещё проверить, чтобы эта сборка и в своих зависимостях тоже ничего опасного не делала

Вариант 3 (для зумеров):
В .NET Core вместо AppDomain предполагается использовать AssemblyLoadContext.
После загрузки плагина, можно посмотреть, какие ещё сборки он загрузил, и выгрузить всё, чему мы не доверяем - например System.IO.FileSystem
(Это я ещё не проверил. Обновлю ответ когда проверю, как это работает)

Comments

[insighter]

Василий Банников, В .NET Core нельзя импортировать DLL с WinAPI функциями?
Если этот импорт можно отследить, то тогда что делать с прокси-DLL.

PS хотя с прокси-DLL наверно не актуально т.к. все это рассматривается в контексте такой ситуации - тебе дают (студенты?)много сборок, которые надо у себя запустить, проверить результат и не хочется чтобы они что то ещё делали

[Василий Банников]

insighter,

В .NET Core нельзя импортировать DLL с WinAPI функциями?

Можно.

Если этот импорт можно отследить, то тогда что делать с прокси-DLL.

С прокси-dll не уверен, тк никогда с такими не сталкивался. Думаю, можно их детектить и просто отказываться грузить
Но просто p/invoke можно отследить по наличию extern-функций и использованию System.Runtime.InteropServices

[Руслан]

Спасибо.
Интересно, можно ли "навредить" в файловой системе только через System.IO.* или существует что-то еще опасное.
Вообще задача сделать общий репозиторий плагинов для определенного софта, куда кто попало сможет загружать свои сборки и при этом защитить всех пользователей этих плагинов от зловредных плагинов.

[Василий Банников]

Руслан,

или существует что-то еще опасное

Конечно существует.
Как минимум, есть ещё Process.Start, ComObject, System.Runtime.InteropServices (P/Invoke), Reflection во всех видах, Emit, компиляция кода в рантайме, компиляция Expression-ов, ну и ещё всякий Unsafe.

и при этом защитить всех пользователей этих плагинов от зловредных плагинов.

Мне кажется, вы заботитесь не о том.
Я бы пошёл вот с такого бока:
Разрешил всё, но дал бы возможность пользователю заблокировать или отследить что и как делает сторонний плагин. Ибо есть много вариантов, как можно с благими намерениями нарушить какое-нибудь правило.

[insighter]

Руслан, конечно, можно просто напрямую работать с Windows API, как я написал выше.
Более того вам надо очень тщательно подойти к тому что можно загружать. Пользователь может вместе с сборкой загрузить не управляемую DLL и импортировать функции оттуда, а что там будет, только догадки строить.

[insighter]

Василий Банников, немного не по теме, ребята на dtf рассказывали, как писали свои dll для проксирования функций старых версий directx на новые, чтобы старые игры играть. Блин, уважаю людей которые подобные штуки делают, и догадались и хватило терпения воплотить.

[Василий Банников]

insighter, думаю, тут немного другое проксирование.
Скорее всего, они сделали свою библиотеку, которая повторяла API старого dx, но вызывала API нового.

[Руслан]

Спасибо за комментарии.
Получается, что задача крайне сложная и опасная (для конечных пользователей). Сложно предусмотреть все возможные точки атак и кроме того, в очередном обновлении .net может появиться что-то новенькое.
Может быть существует какая-то возможность создать что-то вроде виртуальной машины, которая будет изолирована от основного компа и выполнять код плагинов там?

[Василий Банников]

Руслан, вообще есть, но идея плохая :)
Можно запускать плагины в докере и общаться через какой-нибудь grpc

Может просто премодерировать плагины?