Типы объявлений разрешений сборки.

Все классы отрибутов разрешений определяют свойство Action, которое указ., как исполняющая среда будет интерпретировать разрешение.

Свойству Action в кач-ве значений всегда нужно присваивать один из 3 членов SecurityAction:

-SecurityAction.ReguestMinimum – требует разрешение, необходимое для запуска сборки.

Если сборка не имеет указанного разрешенияCAS, исп.среда сгенерир.искл-еSystem.Security.Policy.PolicyException.

- SecurityAction.ReguestOptional – отклоняет все разрешения, не перечисл-е в объявленияхReguestOptional или ReguestMinimum.

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

Если сборка не имеет требуемых разрешенийCAS, исп.среда не будет генерир.искл-я => нужно использ.оба объявления совместноб если сборка не может работать при отсутствии разрешений.

- SecurityAction.ReguestRefuse –ограничивает разрешения, назначенные приложением.

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

Создание объявлений сборки.

Для определения разрешений, которая сборка требует или затрагивает, разработчик использует декларативный CAS.

Using System;

Using System.Security.Permissions;

[assembly: File IOPermissionAttribute

(Security Action.RequestMinimum, Read= @ “C:\ boot.ini”)]namespace NS {}

В примере показана сборка, запрашивает доступ на чтения CAS к файлу C:\ boot.ini. Если ПБ не предоставляет сборки этого разрешения исполняющая среда сгенерирует исключения до запуска сборки. Чтобы повысить защиту сборки укажите SecurityAction.RequestOption или SecurityAction.RequesRefuse в кач-ве св-ва Actionразрешения.

Можно комбинировать различные объявления в одной сборке.

[assembly: Reqistry Permission (SecurityAction.RequestMinnimum, Read=@”HKE_local_Machine\Software”)]

[assembly: Reqistry Permission (SecurityAction.RequestOptional, Read=@”HKE_local_Machine\Software”)]

Если нужно чтобы исполняющая среда генерировала исключение если отсутствует доступ к разделу реестраHKE_local_Machine\Software и не нужно назначить никаких др. разрешений,то следует исп-ть подобные запросы.

Единственное зачем нужно объединять IequestOptimal и Request- отклонение под множество разрешений указанных под множества в объявлении ReqeustOptional.

[assembly:Printing Permission

(Security.Action.RequetMinimum)]

[assembly:FileIOPermissionAttribute

(securityAction.RequstOptional,Read=@”C\”)]

[assembly:FileIOPermissionAttribute

(securityAction.RequstRefuse,Read

=@”C\Windows”)]

Т.е. исполняющая среда будет генерировать исключение, если не имеет разрешение CAS на печать. Т.е. предполагает что исполняющая будет отклонять все разрешения CAS, кроме разрешения чтения и печать доступа диска С. Доступ к папке “C\Windows” будет отклонять. Для выбора объявлений сборок CAS, рекомендуется:

1.использовать объявление сборокRequestMinimum, чтобы добиться требований всех необходимых разрешений, для которых в сборки нет необходимость проверок.

2. Использовать объявление сборокRequesrOptinal?чтобы перечислить все разрешения использование сборкой. Объявить разрешения как можно подробно вкл. все файлы и разделы реестра.

3. использовать объявления сборокRequestReftion, чтобы более подробно настроить разрешения указанные в объявленияRequstOptional.

 

9.Защита методов по правам доступа кода
Защита методов по правам доступа кода.

Как и запросы RBS,CAS можно использовать императивно или декларативно. Однако, запросы CAS авторизуют вызывающий код, а не пользователя.

Типы запроса разрешений методов.

Доступно 6 вариантов для императивного и декларативного запроса в разрешение в методе:

1.assert- инструктирующий исполняющий среды, игнорировать, что вызывающий код может не иметь указанных разрешений. Длясборок должен быть установлен параметр assert any Permission That has been Granted.

2.demand-инструктирует исполняющую среду, генерирует исключения, если вызывающий код и весь вызывающий код стоящий указанных разрешений.

3. deny- приводит к тому, что исполняющая среда ограничивает доступ метода удаляя указанные разрешения.

4.Inheritance Demand-инструктирует исполняющию среду генерирует исключения, если сборка наследующая от класса не имеет указанных разрешений.

5.Link Demand-приводит к тому, что исполняющая среда генерирует исключение, если код непосредственно вызывающий сборку но не любой вызывающий код стоящий в степени не имеет указанных разрешений.

6. PermitOnly-инструктирует исполняющую среду ограничить доступ метода посредством удаление всех разрешений кроме указа.

Два объявления Security.Actionalи 2 видаCodeAccessPermission позволяет исполняющей среде генерировать исключения, если отсутствует разрешения CAS:Demand и Link.

Различия м/у Объявлениями и методами в том,что Demand выполняет проверку разрешений чтобы подтвердить доступ всего вызывающего кода, тогда,как LinkDemand поверяет доступ, только непосредственно всего вызывающего кода, запросы предназначены для поверки разрешения кода вызывающий сборку, а не самой сборкой. для проверки разрешений самой сборки используется методSystem.Security.SecurityManadgere.IsGranted.

Security Actional и методы разрешений инструктирует исполняющую среду ограничить следующие методы CAS:Deny и PermitOnly. Различие состоится в том, что Demand(как и ReqestRefuse) удаляет одно разрешение или набор разрешений, тогда как PermitOnly удаляет все кроме указов.

 

10.Декларативные запросы разрешений CAS
Доступно 6 вариантов для императивного и декларативного запроса в разрешение в методе:

1.assert- инструктирующий исполняющий среды, игнорировать, что вызывающий код может не иметь указанных разрешений. Длясборок должен быть установлен параметр assert any Permission That has been Granted.

2.demand-инструктирует исполняющую среду, генерирует исключения, если вызывающий код и весь вызывающий код стоящий указанных разрешений.

3. deny- приводит к тому, что исполняющая среда ограничивает доступ метода удаляя указанные разрешения.

4.Inheritance Demand-инструктирует исполняющию среду генерирует исключения, если сборка наследующая от класса не имеет указанных разрешений.

5.Link Demand-приводит к тому, что исполняющая среда генерирует исключение, если код непосредственно вызывающий сборку но не любой вызывающий код стоящий в степени не имеет указанных разрешений.

6. PermitOnly-инструктирует исполняющую среду ограничить доступ метода посредством удаление всех разрешений кроме указа.

Два объявления Security.Actionalи 2 видаCodeAccessPermission позволяет исполняющей среде генерировать исключения, если отсутствует разрешения CAS:Demand и Link.

Различия м/у Объявлениями и методами в том,что Demand выполняет проверку разрешений чтобы подтвердить доступ всего вызывающего кода, тогда,как LinkDemand поверяет доступ, только непосредственно всего вызывающего кода, запросы предназначены для поверки разрешения кода вызывающий сборку, а не самой сборкой. для проверки разрешений самой сборки используется методSystem.Security.SecurityManadgere.IsGranted.

Security Actional и методы разрешений инструктирует исполняющую среду ограничить следующие методы CAS:Deny и PermitOnly. Различие состоится в том, что Demand(как и ReqestRefuse) удаляет одно разрешение или набор разрешений, тогда как PermitOnly удаляет все кроме указов.

 

11.Императивные запросы разрешений CAS
Доступно 6 вариантов для императивного и декларативного запроса в разрешение в методе:

1.assert- инструктирующий исполняющий среды, игнорировать, что вызывающий код может не иметь указанных разрешений. Длясборок должен быть установлен параметр assert any Permission That has been Granted.

2.demand-инструктирует исполняющую среду, генерирует исключения, если вызывающий код и весь вызывающий код стоящий указанных разрешений.

3. deny- приводит к тому, что исполняющая среда ограничивает доступ метода удаляя указанные разрешения.

4.Inheritance Demand-инструктирует исполняющию среду генерирует исключения, если сборка наследующая от класса не имеет указанных разрешений.

5.Link Demand-приводит к тому, что исполняющая среда генерирует исключение, если код непосредственно вызывающий сборку но не любой вызывающий код стоящий в степени не имеет указанных разрешений.

6. PermitOnly-инструктирует исполняющую среду ограничить доступ метода посредством удаление всех разрешений кроме указа.

Два объявления Security.Actionalи 2 видаCodeAccessPermission позволяет исполняющей среде генерировать исключения, если отсутствует разрешения CAS:Demand и Link.

Различия м/у Объявлениями и методами в том,что Demand выполняет проверку разрешений чтобы подтвердить доступ всего вызывающего кода, тогда,как LinkDemand поверяет доступ, только непосредственно всего вызывающего кода, запросы предназначены для поверки разрешения кода вызывающий сборку, а не самой сборкой. для проверки разрешений самой сборки используется методSystem.Security.SecurityManadgere.IsGranted.

Security Actional и методы разрешений инструктирует исполняющую среду ограничить следующие методы CAS:Deny и PermitOnly. Различие состоится в том, что Demand(как и ReqestRefuse) удаляет одно разрешение или набор разрешений, тогда как PermitOnly удаляет все кроме указов.

 

12.Домены приложений
Домен приложения — это механизм, реализованный в.NET, который позволяет запустить группу приложений в одном процессе, обеспечивая относительную изоляцию их друг от друга, в то же время позволяя им взаимодействовать друг с другом значительно быстрее, чем в случае отдельных процессов. В Win32 каждое приложение может состоять из одного или нескольких процессов, каждый из которых в свою очередь может порождать один или несколько потоков, таким образом для неуправляемого кода роль изолированной среды выполняет исключительно процесс, а в.NET роль изолированной среды выполняет домен приложения.

Домен полностью изолирует используемые в его рамках ресурсы как от других доменов того же процесса так и от доменов других процессов.

Один процесс может содержать любое число доменов приложения, каждый из которых полностью изолирован от других доменов приложения в рамках данного процесса (а также любого другого процесса). С учетом этого следует понимать, что приложение, выполняющееся в одном домене приложения, не может получить данные (в частности, значения глобальных переменных или статических полей) другого домена приложения иначе, как с помощью протокола удаленного взаимодействия.NET. Для платформы.NET не предполагается прямого однозначного соответствия между доменами приложения и потоками. Напротив, домен приложения может иметь множество потоков, выполняющихся в рамках этого домена в любой момент времени. Кроме того, конкретный поток не привязан к одному домену приложения в течение всего времени существования потока. Потоки могут пересекать границы домена приложения, подчиняясь правилам потоков Win32 и целесообразности CLR. Но, активные потоки могут перемещаться через границы доменов приложения, в любой конкретный момент времени один конкретный поток может выполняться в рамках только одного домена приложения (другими словами, один поток не может работать в нескольких доменах приложения одновременно).

 

13.Классы условий членства. Классы групп кода. Создание доменов приложений с собственными политиками безопасности.

Классы условий членства: существует 8 классов усл. членства которые позволяют указывать соответствующие всему коду или каждому из 7-ми типов доказательств:

1.AllMemberShipCondition

2.AppLocationDirectoryMemberShipCondition
3.HashMemberShipCondition

4.PublisherMemberShipCondition

5.SiteMemberShipCondition

6.StrongNameMemberShipCondition

7.UrlMemberShipCondition

8.ZoneMemberShipCondition
Нужно создавать объект условий членства каждый раз при созд. класса группы кода. Условия членства имеют логические имена, при созд. объекта следует указывать доказательства используемого условия членства.

Класс AllMemberShipCondition не требует указания доказательства т.к. он соответствует всему коду.

Классы групп кода:

1.FileCodeGroup- гр. кода с указанием членства указанных разработчиком и набор разрешений вкл. только разреш. FileIOPermission на доступ к папке из которой был запущен код.
2.FirstMarchCodeGroup- гр. кода которая должна содержать несколько дочерних значений кода.

3.NetCodeGroupe- гр. кода с условием членства указанным разработчиком и набором разрешения WebPermission на доступ к сайту с которого был запущен код.

4.UnionCodeGroupe- в сборнике назначается набор разрешений всех дочерних групп кода с соответствующим условием членства, объединение набора разрешений назначенных родительскому объекту UnionCodeGroup.

Создание доменов приложений с собственными политиками безопасности:
Для этого нужно создать условия членства групп кода утверждения политики, набора разрешений и уровень политики безопасности. Следующтй пример демонстрирует как созд-ть гр. кода использующую условия членства соответств. адреса URL и набор разрешений Internet:
UrlMembershipCondition safeMembership = new UrlMembershipCondition("http://www.microsoft.com/assembly.exe");

PemissionSet safePermissionSet = PolicyLevel.CreateAppDomainLevel().GetNamedPermissionSet("lnternet");

PolicyStatement safePolicyStatement = new PolicyStatement(safePermissionSet);

CodeGroup safeCodeGroup = new UnionCodeGroup (safeMembership, safePolicyStatement);

После определения собственной группы кода нужно создать объект Police.Level и добавить эту группу кода на уровень политики. Police.Level всегда использует корневую группу кода, определённую свойством Police.Level.Root.Code.Group. Следующий пример является расширением предыдущего. В нём определяется уровень политики, создаётся домен приложений, а затем указывается собственный уровень политики в качестве политики безопасности домена приложения.

PolicyLevel safePolicyLevel = PolicyLevel.CreateAppDomainLevel();

safePolicyLevel.RootCodeGroup = safeCodeGroup;

AppDomain myDomain = AppDomain.CreateDomain (“MyDomain”);

myDomain.SetAppDomainPolicy(safePolicyLevel);