Предоставить FullTrust в доверенной сборке, вызываемой частичной доверительной сборкой

Question

Представьте себе следующую среду: приложение XBAP, работающее в режиме частичного доверия (поведение по умолчанию; требовать полного доверия не вариант - но перед тем, как спросить, если XBAP предоставлено полное доверие, все работает как положено) ссылается на локально установленную сборку, который находится в GAC. Для этого мы включаемAllowPartiallyTrustedCallers"опция для локальной сборки, а также полное доверие предоставляется. (представьте, что это своего рода аналог локальной связи)

(кстати, мы знаем об аспектах безопасности при использовании атрибута AllowPartiallyTrustedCallers, но это выходит за рамки этого поста, но все равно)

Теперь, даже если наша локальная сборка GAC имеет полное доверие (мы можем проверить это, позвонив Assembly.GetExecutingAssembly().IsFullyTrusted в любое время), он не выполнит любые требования (неявные или явные), так как он вызывается вызывающим с частичным доверием (наш XBAP). (поправьте меня, если я что-то неправильно понимаю). К счастью, мы можем сделать явные утверждения, чтобы получить разрешения внутри нашей локальной сборки GAC, например:

new System.Security.Permissions.FileIOPermission(.....).Assert();

Таким образом, мы могли бы предотвратить полный просмотр стека по требованию прямо в этот момент и делать любой доступ к файлу, как мы хотим. (еще раз, пожалуйста, поправьте меня...)Это на самом деле работает отлично! (в этом случае)

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

Подход, чтобы решить это:

• Вначале мы подумали о том, чтобы установить набор разрешений (PermissionSet) практически для любого разрешения, прежде чем работать с внешней библиотекой. Это почти работает, но похоже, что в какой-то момент все же возникает исключение безопасности - либо потому, что внешняя библиотека может запустить больше потоков, которые по какой-то причине перестают работать, либо потому, что она получает доступ к сборке входа - на самом деле, мы не знаем.

• Во-вторых, мы попробовали следующий ttribute

[System.Security.Permissions.PermissionSet(
  System.Security.Permissions.SecurityAction.Assert, Name = "FullTrust")]

это тоже не сработало.

• В-третьих, мы подумали об открытии нового AppDomain, превращении полностью доверенной сборки GAC в точку входа AppDomains и выполнении чего-либо внутри этого appdomain - любой обход стека никогда не сможет достичь частично вызывающего доверия абонента - в нашей теории). К сожалению, мы не можем этого достичь... Или вновь созданный AppDomain не отвечает даже более высоким требованиям, даже если он настроен для работы в зонах безопасности MyComputer. Доказательства или неограниченная SecurityPermission. Я не могу явно предоставить полное доверие всему домену приложения.

• В-четвертых, использование caspol не вариант. (из-за причин развертывания)

Теперь, так как это должно быть много информации, я надеюсь, что вы понимаете, что мы хотим архивировать.

Чтобы понять это: как может полностью доверенная сборка установить полное полное доверие к сборкам, которые она вызывает, останавливая все обходы стека для достижения частично доверенного вызывающего?

Спасибо заранее

Answer 1

Глядя на документацию Microsoft в отношении разрешения частично доверенным вызывающим абонентам для сборок с полным доверием, я не верю, что это будет возможно сделать.

Вы продолжаете подчеркивать, что нам нужно избегать проблем с безопасностью, но в действительности то, что вы пытаетесь сделать со своим решением, - это обойти практически каждую часть системы безопасности доступа к коду в.NET Framework, и я буду в затруднении заставил поверить, что вы сможете найти жизнеспособное решение.

Кроме того, я не могу себе представить, что этот процесс действительно нужно делать таким образом.

Не могли бы вы разгрузить эту обработку от частично доверенного абонента, чтобы затем передать сообщения чему-то, работающему локально и уже доверенному?