plik

www.hakin9.org

hakin9 Nr 9/2007

Obrona

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

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:

DJE_25_PL.pdf"

)

;

FileSystemAccessRule _fileAccessRule =

new

FileSystemAccessRule

(

"localhost

dministrator"

FileSystemRights.Read,
AccessControlType.Deny

)

;

_fileSec.AddAccessRule

(

_fileAccessRule

)

;

File

.SetAccessControl

(

"c:

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

ł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:

DJE_25_PL.pdf"

)

;

FileSystemAccessRule _fileAccessRule =

new

FileSystemAccessRule

((

"localhost

dministrator"

FileSystemRights.Read,
AccessControlType.Deny

)

;

_fileSec.RemoveAccessRule

(

_fileAccessRule

)

;

File

.SetAccessControl

(

"c:

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

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

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: arturz@microsoft.com

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:

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"