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