Защита потоков в изолированном домене приложений

У меня есть домен приложения для размещения ненадежного кода / сборки. Я решил все проблемы с безопасностью с атрибутами безопасности, и она работает хорошо. Ненадежный код выполняется в выделенном потоке. CLR составляет 2,0. Это то, что у меня есть AppDomainShell AppDomainSeed, Shell работает в основном домене, seed - доверенный прокси / помощник в ненадежном домене.

Мне интересно ограничить создание новых тем и изменение приоритетов. На данный момент моя ненадежная сборка может установить ThreadPriority.Highest или убить операционную систему, создав 10k потоков. Существует SecurityPermissionFlag.ControlThread, но он предотвращает только сложные операции, такие как Abort().

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

Я думаю, я мог бы использовать некоторые функции Win32, чтобы запретить это на уровне ОС. Но как операционная система распознает поток / код / ​​сборку, которой не доверяют? SetThreadPrincipal ()?

Есть ли какой-либо API CLR, которым можно злоупотреблять? Я предпочитаю решение без необходимости установки и переносимости для Mono:-/ хммм.

Любые другие идеи приветствуются. Спасибо!

Источник

3 ответа

Решение

Я обдумываю другое решение. Статический анализ CIL ненадежной сборки. Я мог искать через все методы, свойства, конструкторы. Распознавать ссылки на типы. Если я нашел ссылку на тип Thread, я выкидываю исключение безопасности и выгружаю сборку.

Мне очень нравится работа Jb Evain. Он создал Mono Cecil, но это довольно тяжелый вес. Он также разработал CIL Reader, только с отражением.NET.

Я создал Linq поверх отражения, используя CIL Reader. Использование выглядит так.


var myAssembly = typeof (Program).Assembly;
foreach (Type usedType in myAssembly.GetUsedTypes())
{
    if (typeof (Thread).IsAssignableFrom(usedType) ||
        typeof (ThreadPool).IsAssignableFrom(usedType) ||
        typeof (ThreadPriority).IsAssignableFrom(usedType)
        )
    {
        throw new SecurityException("Thread usage is banned here!");
    }
}
Источник

Может быть, HostProtectionAttribute - это то, что нужно для ограничения манипулирования потоками ненадежным кодом?

Источник

Потоки выполняются в рамках одного процесса, и вы должны быть в безопасности, так как ваш ненадежный код не может изменить приоритет процесса. (См. MSDN здесь для деталей.)

Я не уверен, что даже создание 10k потоков внутри процесса обязательно убьет Windows - по крайней мере, не любую версию Windows выше Windows NT. Однако ваш процесс почти наверняка перестанет работать, поэтому вы можете рассмотреть два процесса и использовать механизм, такой как удаленное взаимодействие или WCF, для связи между ними.

Источник
Другие вопросы по тегам