Представляю сообществу простой, но полезный инструмент для управления полномочиями доступа к коду .Net сборок – Managed Sandbox. На утилиту советую обратить внимание НЕ только разработчикам, но и всем кто периодически использует .Net программы из не доверенных источников (с небольшими оговорками, но об этом ниже).
Статья состоит из 2-х частей: (1) немного философии о системе безопасности .Net-платформы, (2) описание утилиты Managed Sandbox и причин, почему нужно было ее создавать.
Часть 1. Немного философии. Почему никто не использует широкие возможности управляемого кода по ограничению прав исполнения для обеспечения безопасности?
Вопрос довольно интересный. Сама идея управляемого кода: пожертвовать скоростью исполнения, скоростью загрузки и памятью ради того, чтобы иметь полный контроль над кодом. Полный контроль подразумевает, что мы точно знаем, что именно сделает код и можем запретить ему определенные действия. Практически данная «управляемость» используется лишь для системных целей: разделение контекстов внутри одного процесса, для управления процессом сборки мусора и пр.
А самое главное для обычных пользователей – знать, чем может навредить программа, которую я только что скачал в Сети и запретить ей определенные действия – здесь нет никаких инструментов, даже мало кто знает о таких возможностях .Net программ.
Есть несколько причин, почему сложилась подобная ситуация в мире .Net:
1. 90% .Net программ требуют неограниченных полномочий (т.н. FullTrust). Это связано с тем, что большинство программ используют старые неуправляемые компоненты и библиотеки. К примеру, если вы в своем .Net приложении будете использовать WebBrowserControl – вашей сборке потребуются неограниченные полномочия.
2. Т.к. нет удобных инструментов для контроля доступа к коду (чтобы эти инструменты могли использовать простые пользователи) – никто сильно не задумывался о создании сборок, которые умеют работать с ограниченными правами. Кстати, в .Net 2.0 по умолчанию подписанные библиотеки нельзя было вызывать не имея FullTrust (в .Net 4.0 исправили).
К слову, запуск кода с ограниченными полномочиями активно применяется в ClickOnce. Но опять-же – пользователь не знает что может сделать программа, это знает лишь программист, который установил ограничения при создании дистрибутива.
Часть 2. Зачем нужно создавать утилиту Managed Sandbox, если есть стандартная утилита .Net Configuration от MS, позволяющая ограничивать полномочия кода? В чем разница между программами?
Главная причина – утилита .Net Configuration от MS не очень (точнее очень НЕ) удобна в использовании (про caspol лучше помолчу):
1. Для запуска сборки с ограниченными полномочиями сначала нужно создать новую группу кода, а уж затем определить полномочия для этой группы. После использования программы эти настройки нужно удалить, дабы не засорять конфигурационный файл.
2. .Net Configuration привязывается к версии .Net платформы (для каждой версии платформы нужна своя программа).
3. .Net Configuration позволяет управлять лишь частью полномочий (доступно 19, всего 30). Остальные, видимо, нужно задавать вручную в XML-файле.
4. Ко всему прочему утилита довольно сложна: для ее использования нужно знать основы безопасности .Net. Предназначена она для продвинутых программистов и админов, но никак не для обычных пользователей.
Managed Sandbox намного проще в использовании: нужно лишь выбрать сборку и указать необходимые полномочия исполнения. С этим, пожалуй, сможет справиться любой продвинутый пользователь. Технически для ограничения полномочий используется отдельный домен приложения с соответствующими правами исполнения, конфигурационный файл не изменяется.
Managed Sandbox находится в разработке, многие полномочия пока нет возможности детализировать. Если кто-нибудь захочет принять участие в разработке – милости прошу.
Скачать программу: managedsandbox.codeplex.com/releases/view/51827
Скачать исходный код: managedsandbox.codeplex.com/SourceControl/list/changesets
Статья состоит из 2-х частей: (1) немного философии о системе безопасности .Net-платформы, (2) описание утилиты Managed Sandbox и причин, почему нужно было ее создавать.
Часть 1. Немного философии. Почему никто не использует широкие возможности управляемого кода по ограничению прав исполнения для обеспечения безопасности?
Вопрос довольно интересный. Сама идея управляемого кода: пожертвовать скоростью исполнения, скоростью загрузки и памятью ради того, чтобы иметь полный контроль над кодом. Полный контроль подразумевает, что мы точно знаем, что именно сделает код и можем запретить ему определенные действия. Практически данная «управляемость» используется лишь для системных целей: разделение контекстов внутри одного процесса, для управления процессом сборки мусора и пр.
А самое главное для обычных пользователей – знать, чем может навредить программа, которую я только что скачал в Сети и запретить ей определенные действия – здесь нет никаких инструментов, даже мало кто знает о таких возможностях .Net программ.
Есть несколько причин, почему сложилась подобная ситуация в мире .Net:
1. 90% .Net программ требуют неограниченных полномочий (т.н. FullTrust). Это связано с тем, что большинство программ используют старые неуправляемые компоненты и библиотеки. К примеру, если вы в своем .Net приложении будете использовать WebBrowserControl – вашей сборке потребуются неограниченные полномочия.
2. Т.к. нет удобных инструментов для контроля доступа к коду (чтобы эти инструменты могли использовать простые пользователи) – никто сильно не задумывался о создании сборок, которые умеют работать с ограниченными правами. Кстати, в .Net 2.0 по умолчанию подписанные библиотеки нельзя было вызывать не имея FullTrust (в .Net 4.0 исправили).
К слову, запуск кода с ограниченными полномочиями активно применяется в ClickOnce. Но опять-же – пользователь не знает что может сделать программа, это знает лишь программист, который установил ограничения при создании дистрибутива.
Часть 2. Зачем нужно создавать утилиту Managed Sandbox, если есть стандартная утилита .Net Configuration от MS, позволяющая ограничивать полномочия кода? В чем разница между программами?
Главная причина – утилита .Net Configuration от MS не очень (точнее очень НЕ) удобна в использовании (про caspol лучше помолчу):
1. Для запуска сборки с ограниченными полномочиями сначала нужно создать новую группу кода, а уж затем определить полномочия для этой группы. После использования программы эти настройки нужно удалить, дабы не засорять конфигурационный файл.
2. .Net Configuration привязывается к версии .Net платформы (для каждой версии платформы нужна своя программа).
3. .Net Configuration позволяет управлять лишь частью полномочий (доступно 19, всего 30). Остальные, видимо, нужно задавать вручную в XML-файле.
4. Ко всему прочему утилита довольно сложна: для ее использования нужно знать основы безопасности .Net. Предназначена она для продвинутых программистов и админов, но никак не для обычных пользователей.
Managed Sandbox намного проще в использовании: нужно лишь выбрать сборку и указать необходимые полномочия исполнения. С этим, пожалуй, сможет справиться любой продвинутый пользователь. Технически для ограничения полномочий используется отдельный домен приложения с соответствующими правами исполнения, конфигурационный файл не изменяется.
Managed Sandbox находится в разработке, многие полномочия пока нет возможности детализировать. Если кто-нибудь захочет принять участие в разработке – милости прошу.
Скачать программу: managedsandbox.codeplex.com/releases/view/51827
Скачать исходный код: managedsandbox.codeplex.com/SourceControl/list/changesets
