Poniższy artykuł pochodzi z serii Przygotowań do egzaminu 70-536.
Powody do używania CAS Assembly Declarations
Głównie z trzech powodów używamy CAS Assembly Declarations:
1. Aby zapewnić, że runtime nigdy nie uruchomi aplikacji bez uprawnień do pożądanych zasobów.
2. Do stworzenia tzw. “piaskownicy” dla naszej aplikacji po to, aby atakujący nie mógł nią manipulować
3. Aby zweryfikować, że aplikacja może być uruchomiona z ograniczeniami dostępu CAS
Klasy dla uprawnień CAS
CAS może ograniczyć dostęp do różnego rodzaju zasobów: plików, folderów, drukarek, dostępu do sieci. Dla każdego rodzaju zasobu, który może być chroniony, .NET dostarcza odpowiednie klasy np:
DataProtectionPermission – dostęp do zaszyfrowanych danych i pamięci
DirectoryServicesPermission – dostęp do klas System.DirectoryServices
DnsPermission – dostęp do DNS
EnvironmentPermission – czytanie lub tworzenie zmiennych środowiskowych
FileDialogPermission – dostęp do plików, które zostały wybrane przez użytkownika w dialog boxie
FileIOPermission – czytanie, dodawanie, tworzenie plików lub folderów
PrintingPermission – dostęp do drukarki
RegistryPermission – działania na rejestrze
ServiceControllerPermission – dostęp do usług
SqlClientPermission – dostęp do serwera SQL
OraclePermission – dostęp do bazy oracla
PerformanceCounterPermission – dostęp do liczników wydajności
To tylko niektóre klasy. Training Kit dodatkowo podaje jeszcze takie jak: IUnrestrictedPermission, KeyContainerPermission, MessageQueuePermission, EventLogPermission, AspNetHostingPermission, WebPermission, UrlIdentityPermission,UIPermission.
Ponieważ klasy te są dziedziczone po CodeAccessSecurityAttribute, niektóre metody i właściwości mają wspólne jednak najczęściej będziemy korzystali z dwóch standardowych właściwości:
Action – określa działania zabezpieczeń. Ustawiamy za pomocą enumeracji SecurityAction
Unrestricted – wartość typu Boolean, która określa dostęp do wszystkich zasobów.
Typy Assembly Permission Declaration
Kiedy tworzymy deklarację assembly CAS, musimy ustawić właściwość Action na jedną z trzech możliwych opcji:
1. SecurityAction.RequestMinimum – wymaga pozwolenia na uruchomienie assembly. Jesli assembly nie bedzie miała określonych uprawnień CAS, zostanie wyrzucony wyjątek PolicyException.
2. SecurityAction.RequestOptional – definiowanie uprawnień z tym działaniem zapewnia, że aplikacja nie będzie miała więcej uprawnień niż te, które zostały wymienione w SecurityAction.RequestOptional lub SecurityAction.RequestMinimum
3. SecurityAction.RequestRefuse – zmniejsza uprawnienia przypisane do naszej aplikacji.
Jak stworzyć Assembly Declaration
Poniższy kod pokazuje assembly, która wymaga uprawnień CAS do odczytu pliku C:\Windows\Win.ini.
1: using System.Security.Permissions;
2:
3: [assembly:FileIOPermissionAttribute(SecurityAction.RequestMinimum,
4: Read=@"C:\windows\win.ini")]
5: namespace DeclarativeExample
6: {
7: class Program
8: {
9: static void Main(string[] args)
10: {
11: Console.WriteLine("Hello, World!");
12: }
13: }
14: }
W powyższym przykładzie użyłem SecurityAction.RequestMinimum. który spowoduje, że zostanie wyrzucony wyjątek jeśli assembly nie będzie miała uprawnień do odczytu pliku.
Aby poprawić zabezpieczenia assembly, możemy określić SecurityAction.RequestOptional lub
SecurityAction.RequestRefuse dla właściwości Action. Opcjonalnie możemy połączyć kilka deklaracji w pojedynczej assembly. Na przykład, jeśli chcemy żeby runtime rzucił wyjątek gdy nie mamy dostępu do klucza w rejestrze HKEY_LOCAL_MACHINE\Software i nie chcemy żadnych innych ograniczeń CAS, możemy użyć poniższych deklaracji:
1: [assembly:RegistryPermission(SecurityAction.RequestMinimum,
2: Read=@"HKEY_LOCAL_MACHINE\Software")]
3: [assembly: UIPermission(SecurityAction.RequestMinimum, Unrestricted = true)]
4: [assembly: RegistryPermission(SecurityAction.RequestOptional,
5: Read=@"HKEY_LOCAL_MACHINE\Software")]
I to właściwie wszystko na dzisiaj :) Tym razem życzę Wam Szczęśliwego Nowego Roku :)
Kolejny artykuł z serii to 70-536 Using Declarative and Imperative Security to Protect Methods
