www.hakin9.org

hakin9 Nr 9/2007

48

Obrona

W

systemach zorientowanych obiekto-
wo własne listy kontroli dostępu ma-
ją obiekty reprezentujące zasoby,

takie jak serwery plików i drukarki. Jedna lista
ACL może określać prawa dostępu/zezwolenia
dla wielu różnych użytkowników. Z reguły listę
kontroli dostępu może zmieniać właściciel ka-
talogu lub pliku. Bezpośrednio po instalacji sys-
temu jest to administrator. Listy kontroli dostę-
pu zaimplementowano m. in. w systemach No-
vell NetWare, UNIX, Microsoft Windows NT.
Taką definicję możemy znaleźć bardzo czę-
sto w Internecie i jest to w zasadzie najlepsza i
najbardziej obszerna definicja ACL. Ta pocho-
dzi ze strony wydawnictwa Robomatic (http://
www.robomatic.pl/?id=enchaslo&idh=15).

Programistyczny dostęp do ACL możliwy

jest poprzez przestrzeń nazw System.Securi-
ty.AccessControl. Pozwala ona na tworzenie i
modyfikowanie arbitralnej (DACL – Discretio-
nary Access Control List) oraz systemowej li-
sty kontroli (SACL – System Access Control
List) dla różnych chronionych obiektów – takich
jak pliki, foldery i inne elementy. Listy DACL
pozwalają na programistyczną kontrolę do-
stępu do chronionych zasobów, podczas gdy
SACL pozwala na kontrolę polis systemowych.
Przykład – DACL pozwala na ustawienie dostę-

pu do odczytania pliku dla konkretnej osoby, a
SACL pozwala na logowanie tego, że ktoś da-
ny plik otworzył.

Artykuł ma na celu przedstawienie, w ja-

ki sposób wykorzystać dostępne mechanizmy
przy budowaniu własnych aplikacji.

Poznajemy klasy ACL

Jeśli przyjrzymy się zawartości przestrzeni nazw
System.Security.AccessControl to znajdziemy
tam bardzo wiele klas odpowiedzialnych za róż-
ne elementy systemu. Możemy je podzielić we-
dług różnych aspektów. Podział taki przedstawia

Access Control List (ACL)

– dostęp do obiektów .NET

Artur Żarski

stopień trudności

Access Control List, czyli lista kontroli dostępu, to lista lub tabela

skojarzona z plikiem bądź obiektem, zawierająca informacje o

użytkownikach, procesach lub obiektach, które mogą uzyskiwać

do niego dostęp. Listy ACL są z reguły przypisane do katalogów w

systemie plików oraz do innych obiektów i określają prawa dostępu

użytkownika, takie jak prawo odczytu, zapisu, usuwania, itp.

Co powinieneś wiedzieć

• Aby zrozumieć tekst, należy cechować się pod-

stawową znajomością zasad kontroli dostępu
do obiektów w systemie operacyjnym

• znać pojęcia ACL, ACE i pokrewne.

Z artykułu dowiesz się

• Artykuł ma na celu przybliżenie podstawowych

elementów mechanizmu ACL

• przedstawienie sposobów programowania list

kontroli dostępu z poziomu Microsoft.NET.

Access Control List

hakin9 Nr 9/2007

www.hakin9.org

49

Tabela 1. Nie jest to lista wszystkich
dostępnych klas, ale obejmuje najbar-
dziej popularne obszary.

Hierarchia klas ACL

W przypadku większości scenariuszy
możliwe jest użycie klas abstrakcyjnych
zamiast zaawansowanych klas do two-
rzenia i modyfikacji ACL. Dla każdego
zasobu klasy wyższego poziomu mogą
przybrać następujące formy:

• Klasa, która enkapsuluje arbitralne

listy kontroli dostępu (DACL) oraz
systemowe listy kontroli (SACL).
Klasa taka przyjmuje nazwę „<Na-
zwaZasobu>Security” – dla przy-
kładu FileSecurity oraz Directory-
Security.

• Klasa, która enkapuluje wpis dla

liście (ACE – Access Control En-
try). Klasa taka przyjmuje nazwę
„<NazwaZasobu>AccessRule”

• Klasa, która enkapsuluje zawar-

tość wpisu ACE. Klasa taka przyj-
muje nazwę „<NazwaZasobu>Au-
ditRule”

Dodatkowo klasa może przyjąć po-
stać iteratorów, które pozwalają na
tworzenie specyficznych reguł do-
stępu oraz audytu.

Dodawanie wpisu do listy

Po utworzeniu wpisu przy użyciu jed-
nej z klas reguł dostępu lub klas re-

guł audytu, możliwe jest przypisanie
tej reguły do zasobu lub użycie jej do
skasowania już istniejącej reguły. Li-
sting 1. pokazuje przykład stworze-
nia reguły oraz zastosowania jej na
pliku. Fragment kodu podaje regułę
zabronienia odczytu pliku *.PDF na
dysku użytkownikowi lokalnemu ad-
ministrator. Po uruchomieniu tej pro-
cedury próba otwarcia dokumentu
zakończy się błędem braku dostępu
(Rysunek 1). Jeśli zobaczymy wła-
ściwości pliku w systemie, to również

zauważymy, że dla wybranego użyt-
kownika dostęp do pliku (do czyta-
nia) jest zabroniony. Przedstawia to
Rysunek 2.

Aby skasować taki zapis należy

wykonać fragment załączony na Li-
stingu 2. Najważniejsze w obu przy-
padkach są metody

AddAccessRule

oraz

RemoveAccessRule

, które usta-

wiają lub usuwają reguły.

Dodając jakiś wpis, który da-

je nam dostęp do pewnego zaso-
bu nie mamy gwarancji, że ta regu-

Tabela 1.

Zestawienie klas w przestrzeni nazw System.Security.AccessControl

Obszar

Klasy

Klucze kryptograficzne

CryptoKeySecurity
CryptoKeyAccessRule
CryptoKeyAuditRule

Katalogi

DirectorySecurity
FileSystemAccessRule
FileSystemAuditRule

Pliki

FileSecurity
FileSystemAccessRule
FileSystemAuditRule

Muteksy

MutexSecurity
MutexAccessRule
MutexAuditRule

Rejestr

RegistrySecurity
RegistryAccessRule
RegistryAuditRule

Semafory

SemaphoreSecurity
SemaphoreAccessRule
SemaphoreAuditRule

Listing 1.

Dodanie reguły zabraniającej odczytu dla pliku

FileSecurity _fileSec =

File

.GetAccessControl

(

@

"c:

\S

DJE_25_PL.pdf"

)

;

FileSystemAccessRule _fileAccessRule =

new

FileSystemAccessRule

(

@

"localhost

\a

dministrator"

,

FileSystemRights.Read,
AccessControlType.Deny

)

;

_fileSec.AddAccessRule

(

_fileAccessRule

)

;

File

.SetAccessControl

(

@

"c:

\S

DJE_25_PL.pdf"

, _fileSec

)

;

Rysunek 1.

Błąd odczytu – zakaz dostępu – podczas próby odczytania

pliku, na którym została założona reguła

Rysunek 2.

Właściwości pliku w

systemie operacyjnym. Zabroniony
odczyt dla wybranego użytkownika

hakin9 Nr 9/2007

www.hakin9.org

Obrona

50

ła będzie zastosowana. Spowodo-
wane jest to tym, że reguły, które za-
braniają dostępu mają wyższy prio-
rytet i zawsze nadpisują reguły da-
jące dostęp.

Każdy obiekt zgodny z konwen-

cją <NazwaZasobu>Security do-
starcza szeregu metod do dodawa-
nia lub kasowania reguł dostępu i re-
guł audytu. Metody te przedstawione
są w Tabeli 2.

Reguły propagacji ACL

Podczas tworzenia lub modyfikacji
odpowiednich wpisów (ACE – Ac-
cess Control Entries) dla kontenera
obiektów takich jak np. foldery, moż-
liwe jest wyspecyfikowanie sposo-
bu propagacji wpisów na poszcze-
gólnych obiektach wewnątrz dane-
go kontenera. Dla przykładu możliwe
jest zastosowanie reguł na podfolde-
rach, a na plikach już nie.

Reguły propagacji kontrolowane

są przez różne kombinacje flag dzie-
dziczenia oraz flag propagacji. Róż-
ne kombinacje flag i ich efektów pro-
pagacji pokazuje Tabela 3.

Scenariusze

zastosowania ACL

Przykładów zastosowań ACL jest
wiele. Przede wszystkim możemy
stworzyć aplikację, dzięki której w
szybki sposób możemy dostać listę
obiektów i uprawnień związanych z
obiektami. Listing 3 pokazuje kod,
który dla zadanego pliku pokazuje, ja-

Listing 2.

Usunięcie reguły zabraniającej odczytu pliku

FileSecurity _fileSec =

File

.GetAccessControl

(

@

"c:

\S

DJE_25_PL.pdf"

)

;

FileSystemAccessRule _fileAccessRule =

new

FileSystemAccessRule

((

@

"localhost

\a

dministrator"

FileSystemRights.Read,
AccessControlType.Deny

)

;

_fileSec.RemoveAccessRule

(

_fileAccessRule

)

;

File

.SetAccessControl

(

@

"c:

\S

DJE_25_PL.pdf"

, _fileSec

)

;

Tabela 2.

Zestawienie metod i ich funkcjonalności

Metoda

Opis

AddAccessRule
AddAuditRule

Wyszukuje takiej reguły dostępu lub audytu, która może być połączona z no-
wą regułą. Jeśli żadna nie zostanie odnaleziona, dodaje nową regułę.

SetAccessRule
SetAuditRule

Kasuje wszystkie reguły dostępu z tymi samymi: użytkownikiem oraz warto-
ścią typu dostępu (AccessControlType i wartości Allow oraz Deny), co w wy-
specyfikowanej regule, a następnie dodaje stworzoną regułę.

ResetAccessRule

Działa podobnie jak SetAccessRule, ale nie zwraca uwagi na wartość Acces-
sControlType.

RemoveAccessRule
RemoveAuditRule

Poszukuje reguł kontroli dostępu dla tych samych: użytkownika oraz wartości
AccessControlType (Allow lub Deny), jak we wskazanej regule, a także z od-
powiednią flagą propagacji i dziedziczenia. Jeśli znajdzie, to prawa zawierają-
ce wyspecyfikowaną regułę zostają skasowane z reguły.

RemoveAccessRuleAll
RemoveAuditRuleAll

Szuka wszystkich reguł z tymi samymi: użytkownikiem oraz wartością Acces-
sControlType, co w wyspecyfikowanej regule i – jeśli znajdzie – kasuje te reguły.

RemoveAccessRuleSpecific
RemoveAuditRuleSpecific

Wyszukuje wszystkich reguł, które dokładnie pasują do wyspecyfikowanych
reguł i – jeśli znajdzie – kasuje te reguły.

Rysunek 3.

Wynik działania programu z Listingu 3

Rysunek 4.

Lista uprawnień dla pliku konfiguracyjnego web.config

Access Control List

hakin9 Nr 9/2007

51

kie uprawnienia ma dana grupa użyt-
kowników lub użytkownik. Kod ten
składa się z trzech części. Pierwsza
z nich to otwarcie wybranego pliku. W
drugiej części dla wcześniej wybra-
nego pliku pobieramy listę uprawnień.
W ostatnim kroku wypisujemy ele-
menty dostępne na liście uprawnień
– w kolejności: użytkownik/grupa,
uprawnienie oraz typ uprawnienia
– zabroniony/dozwolony. Rysunek 3
pokazuje wynik działania programu.

Oczywiście spośród innych sce-

nariuszy możemy wyobrazić sobie
sytuację, kiedy nasz system automa-
tycznie generuje jakieś pliki i nadaje
im uprawnienia. Kroki, jakie należa-
łoby wykonać to:

• Stworzenie jednej lub wielu re-

guł reprezentowanych przez kla-
sy FileSystemAccessRule lub Fi-
leSystemAuditRule,

• Dodanie wcześniej stworzonych

obiektów do nowych obiektów re-
prezentujących klasy FileSecuri-
ty lub DirectorySecurity,

• Utworzenie pliku lub folderu z wy-

korzystaniem wcześniej stworzo-
nych reguł. Dla przykładu można
użyć następującej deklaracji:

Ciemna strona mocy

Powiedzieliśmy dużo o zaletach ACL
i sposobie programowania. Istnieje
również druga strona medalu. Jeśli
nasz system będzie źle skonfiguro-
wany (np. w przypadku instalacji bar-
dzo ważnej aplikacji WWW), niepo-
wołany użytkownik zyska możliwość
uzyskania danych zawartych w na-
szych plikach.

Wyobraźmy sobie sytuację, w

której plik konfiguracyjny aplikacji
WWW – web.config – będzie mieć
takie same uprawnienia, jak nasz
plik i użytkownik, z uprawnienia-
mi którego działa nasza aplikacja
WWW. Możliwa jest sytuacja, kie-
dy napiszemy aplikację, która bę-
dzie poszukiwać określonych plików
i wyciągać z nich dane. Jeśli przyj-
rzymy się Rysunkowi 4, to może-
my zauważyć, że do naszego pliku
konfiguracyjnego ma dostęp użyt-
kownik IIS_IUSRS. Jeśli plik ten
będzie zawierać odpowiednie in-

hakin9 Nr 9/2007

www.hakin9.org

Obrona

52

formacje, to w bardzo prosty spo-
sób będziemy mogli uzyskać dane
o użytkowniku oraz haśle, na któ-
rym działa aplikacja. Trzeba pamię-
tać, aby brać to pod uwagę i odpo-
wiednio konfigurować dostęp do pli-
ków. Dodatkowo uważać trzeba, je-

śli nasza strona WWW daje możli-
wość ładowania aplikacji przy wyko-
rzystaniu kontrolki FileUpload – dla-
czego? Dlatego, że użytkownik mo-
że wgrać plik o nazwie web.config,
który będzie zawierał zupełnie inne
informacje niż oczekuje tego nasza

aplikacja. Może się to okazać zgub-
ne przy zastosowaniu ataków typu
Denial-of-Service.

Podsumowanie

Mechanizm Access Control List defi-
niuje nam sposób dostępu do obiek-
tów. Microsoft.NET bardzo mocno
wspiera ACL oraz możliwości opro-
gramowania go, aby aplikacje, któ-
re tworzymy, mogły działać zgodnie
z regułami bezpieczeństwa obowią-
zującymi w naszych firmach. Nale-
ży oczywiście uważać, w jaki spo-
sób używamy tego sposobu dostępu
do uprawnień, ponieważ przez nie-
dopatrzenie możemy tak poustawiać
uprawniania do plików lub folderów,
że nawet sami (jako administratorzy)
będziemy mieć problem z dostępem
do odpowiednich zasobów. l

O autorze

Autor jest pracownikiem firmy Micro-
soft. Na co dzień zajmuje się m. in. two-
rzeniem rozwiązań w oparciu o SQL
Server w różnych aspektach – bazy re-
lacyjne, usługi integracyjne, usługi ana-
lityczne. Jest certyfikowanym admini-
stratorem baz danych (MCDBA). Kon-
takt z autorem: [e-mail]

Tabela 3.

Zestawienie flag i odpowiadające im sposoby propagacji

Kombinacja flag

Propagacja

Brak flag

Docelowy folder

ObjectInherit

Docelowy folder, obiekt podrzędny (plik), obiekt pod-
rzędny do obiektu podrzędnego (plik)

ObjectInherit i NoPropagateInherit

Docelowy folder, obiekt podrzędny (plik)

ObjectInherit i InheritOnly

Obiekt podrzędny (plik), obiekt podrzędny do obiektu
podrzędnego (plik)

ObjectInherit, InheritOnly oraz NoPropagateInherit

Obiekt podrzędny (plik)

ContainerInherit

Docelowy folder, podfolder, podfolder dla podfolderu

ContainerInherit oraz NoPropagateInherit

Docelowy folder, podfolder

ContainerInherit oraz InheritOnly

Podfolder, podfolder dla podfolderu

ContainerInherit, InheritOnly, oraz NoPropagateInherit

Podfolder

ContainerInherit oraz ObjectInherit

Docelowy folder, podfolder, obiekt podrzędny (plik), pod-
folder dla podfolderu, obiekt podrzędny do obiektu pod-
rzędnego (plik)

ContainerInherit, ObjectInherit oraz NoPropagateInherit Folder docelowy, podfolder, obiekt podrzędny (plik)
ContainerInherit, ObjectInherit oraz InheritOnly

Podfolder, obiekt podrzędny (plik), podfolder dla podfol-
deru, obiekt podrzędny do obiektu podrzędnego (plik)

ContainerInherit, ObjectInherit, NoPropagateInherit, In-
heritOnly

Podfolder, obiekt podrzędny (plik)

Listing 3.

Kod wypisujący listę uprawnień dla pliku.

FileStream _file =

new

FileStream

(

@

"c:

\S

DJE_25_PL.pdf"

,

FileMode.Open,
FileAccess.ReadWrite

)

;

FileSecurity _sec = _file.GetAccessControl

()

;

foreach

(

FileSystemAccessRule rule in _sec.GetAccessRules

(

true,

true, typeof

(

System.Security.Principal.NTAccount

)))

{

listBox1.Items.Add

(

rule.IdentityReference.ToString

()

+

" - "

+

rule.FileSystemRights.ToString

()

+

" - "

+

rule.AccessControlType.ToString

())

;

}

Listing 4.

Stworzenie pliku lub folderu za pomocą wcześniejszych reguł

System.IO.

File

.Create

(

System.

String

,System.Int32,System.IO.FileOptions,Syste

m.Security.AccessControl.FileSecurity

)

System.IO.Directory.CreateDirectory

(

System.

String

,System.Security.AccessCont

rol.DirectorySecurity

)

Listing 5.

Fragment kodu umożliwiający uzyskanie informacji

o użytkowniku i haśle

<

identity impersonate=

"true"

userName=

"domena\mojUzytkownik"

password=

"TrudneHaslo"

/

>