Comments 7
Классно
Сборка ссылается на огромное множество стандартных библиотек .NET, и анализировать их бессмысленно - в них не может быть вредоносного кода.
А это точно так? В них может быть код, который позволит вредоносному плагину выполнять произвольные действия. Например, как вы отловите ситуацию, если загружаемая сборка создаст экземпляр "запрещенного" типа с помощью десериализатора? А если в ней используется dynamic, как это проанализировать? И т.д. - составить исчерпывающий список запрещенных API не представляется возможным, и сам по себе подход будет бесконечным затыканием дырок, каждая из которых может быть фатальна для проекта.
Сами эти сборки лишь предоставляют возможности, внутри них ведь нет заранее заготовленных скриптов, которые предназначены для атаки на систему. А вот возможности этих сборок могут использоваться пользовательскими сборками - которые как раз могут использовать их во вред - моя задача проверять такие пользовательские сборки. Большое спасибо за наводку про dynamic и десериализацию! С dynamic не должно возникнуть проблем, поскольку я запретил использование рефлексии, а реализация подделочных сервисов проверяется статическим анализатором. Но я в любом случае протестирую эти сценарии, большое спасибо за обратную связь!
Для кого и каких целей это задумано?
Если пользователь - обычный человек, то ему система разрешений сложна и непонятна. Будет написано "скачайте плагин со страницы гитхаба и настройте вот так" - он и настроит вот так.
Как ограничили пути - не уловил, System.IO запрещено, как в принципе тогда работать должны плагины с диском? Относительные пути проработаны ли - тоже не понял. Сразу отмечу - у вас путь в примерах с косой чертой, которая отличается на windows\linux системах, т.е. конфиг получился системо-зависимый?
В целом, в дотнете когда то были домены для создания "песочниц", но даже они не были идеальным решением. Сейчас что в неткоре - совсем не в курсе, переделывали эту штуку.
Система безопасности является опциональной - если пользователю она не нужна или он не хочет разбираться он может ее отключить. Я полностью согласен с тем, что система разрешений получилась сложной. Однако благодаря этому получилось добиться строгого
контроля.
Как устроено ограничение путей:
Интерфейсы безопасных сервисов находятся в слое API.
Реализации этих интерфейсов — в отдельной инфраструктурной сборке.
Пространства имён, вроде
System.IO, используются только в инфраструктурной сборке.API ничего не знает о конкретных реализациях. Плагины работают с интерфейсами (контрактами), а не с конкретными типами.
Так как API не ссылается на инфраструктурную сборку, сама инфраструктура остаётся вне системы безопасности.
Проверяются только:
Сборки с плагинами.
Сборки, на которые эти плагины напрямую ссылаются.
При добавлении допустимых разрешений все пути проходят нормализацию - то есть относительные пути прорабатываются. А при указании необходимых разрешений в конфигурации плагина необходимо указывать абсолютный путь. Спасибо что указали на зависимость конфига от операционной системы, исправлю этот момент в нормализации путей. Большое спасибо за обратную связь!
Что с вызовом нативных функций?
Как я создал систему безопасности для плагинов: от идеи до реализации