praca mag Modele kontroli dostępu do zasobów i ich wpływ na bezpieczeństwo sys komp

Katolicki Uniwersytet Lubelski
Wydział Matematyczno–Przyrodniczy

Instytut Matematyki

Krystian Matusiewicz

nr albumu 63361

Modele kontroli dostępu do zasobów

i ich wpływ na bezpieczeństwo systemów

komputerowych

Praca magisterska wykonana na seminarium

„Ochrona informacji w sieciach komputerowych”

pod kierunkiem prof. dr. hab. Pawła Urbanowicza

Lublin, 2002

Spis treści

Wstęp

1 Ochrona informacji w systemie informatycznym

1.1 Podstawowe pojęcia i mechanizmy . . . . . . . . . . . . . . . . . . . .

1.2 Polityka bezpieczeństwa a mechanizm kontroli dostępu . . . . . . . .

1.3 Bezpieczeństwo a funkcjonalność systemu . . . . . . . . . . . . . . . . 10

2 Uznaniowa kontrola dostępu

2.1 Ogólny model macierzy dostępu . . . . . . . . . . . . . . . . . . . . . 11
2.2 Model Harrisona – Ruzzo – Ullmana i nierozstrzygalność problemu

przecieku praw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3 Wpływ ograniczeń na złożoność problemu

przecieku praw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4 Model macierzy dostępu z typami obiektów . . . . . . . . . . . . . . . 19
2.5 Gramatyczne systemy ochrony . . . . . . . . . . . . . . . . . . . . . . 23
2.6 Model „przejmij–przekaż” . . . . . . . . . . . . . . . . . . . . . . . . 29
2.7 Podsumowanie cech uznaniowej kontroli dostępu . . . . . . . . . . . . 32

3 Obowiązkowa kontrola dostępu

3.1 Model Bell–La Padula . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2 Model kratowy Denning . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3 Model kratowy dla polityki chińskiego muru . . . . . . . . . . . . . . 43
3.4 Podsumowanie własności obowiązkowej kontroli dostępu . . . . . . . 46

4 Kontrola dostępu oparta na rolach

4.1 Model Sandhu–Coyne kontroli opartej na rolach . . . . . . . . . . . . 47
4.2 Role administracyjne . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3 RBAC a inne modele kontroli dostępu . . . . . . . . . . . . . . . . . 53

4.4 Podsumowanie cech RBAC . . . . . . . . . . . . . . . . . . . . . . . . 56

5 Proponowany model kontroli dostępu wraz z przykładową imple-

mentacją

5.1 Opis modelu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.1.1 Elementy składowe . . . . . . . . . . . . . . . . . . . . . . . . 58
5.1.2 Powiązania pomiędzy elementami . . . . . . . . . . . . . . . . 59

5.2 Analiza cech modelu . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.3 Projekt i implementacja systemu . . . . . . . . . . . . . . . . . . . . 62

5.3.1 Odwzorowanie elementów modelu w klasy . . . . . . . . . . . 63
5.3.2 Niektóre zagadnienia implementacyjne . . . . . . . . . . . . . 64

5.4 Kierunki dalszego rozwoju . . . . . . . . . . . . . . . . . . . . . . . . 67

Bibliografia

Dodatki

A. Specyfikacja protokołu komunikacyjnego . . . . . . . . . . . . . . . . . 73
B. Definicja DTD i opis pliku konfiguracji . . . . . . . . . . . . . . . . . . 80
C. Rodzaje praw dostępu w klasie FSPermission . . . . . . . . . . . . . . 82

Praca niniejsza zajęła I miejsce

Konkursie Prac Magisterskich i Inżynierskich w dziedzinie

kryptografii i ochrony informacji,

zorganizowanym w ramach VI Krajowej Konferencji Zastosowań Kryptografii

ENIGMA 2002

, która odbyła się w dniach 15–17 maja 2002 roku w Warszawie.

Enigma Systemy Ochrony Informacji, http://www.enigma.com.pl

Wstęp

Rozwój sprzętu komputerowego i technologii komunikacyjnych, jaki dokonał się na
przestrzeni ostatnich 30 lat, stworzył zupełnie nowe możliwości przetwarzania infor-
macji.

Przydatność komputerów jako narzędzi służących do gromadzenia i przetwarza-

nia danych spowodowała, że obecnie ogromna ilość różnorodnych informacji, często
o dużej wartości, jest gromadzona w postaci elektronicznej. Jednocześnie ogólna do-
stępność środków elektronicznej komunikacji spowodowała, że coraz większa ilość
informacji jest wymieniana pomiędzy różnymi systemami i coraz więcej zasobów
dostępnych jest dla wielu potencjalnych użytkowników.

Sytuacja w której wielu użytkowników ma dostęp do danych powoduje powstanie

problemów ochrony informacji przed nieautoryzowanym dostępem. W takiej sytuacji
koniecznością jest opracowanie mechanizmów pozwalających na przydzielanie bądź
odmowę dostępu do danych zgodnie z przyjętymi regułami polityki bezpieczeństwa
informacji.

Centralną ich częścią jest mechanizm kontroli dostępu (ang. access control) który

w oparciu o to kto i do jakiej informacji żąda dostępu, decyduje czy dostęp ten
przyznać czy nie.

Celem pracy jest przebadanie matematycznych modeli mechanizmów kontroli

dostępu do zasobów i ich własności. Opisane zostaną ważniejsze teoretyczne modele
mechanizmów kontroli dostępu oraz przeprowadzona zostanie ich analiza pod ką-
tem możliwego do osiągnięcia bezpieczeństwa informacji, elastyczności w wyrażaniu
zróżnicowanych polityk bezpieczeństwa i przydatności w praktycznych zastosowa-
niach.

Przedstawiony zostanie również własny model kontroli dostępu rozszerzający

funkcjonalność kontroli opartej na rolach oraz pokazany zostanie proces implemen-
towania modelu na potrzeby przykładowego zastosowania jakim będzie sieciowy
system współdzielenia plików.

Rozdział 1

Ochrona informacji w systemie

informatycznym

1.1

Podstawowe pojęcia i mechanizmy

Ze względu na informację przechowywaną jako dane w systemach komputerowych,
możemy wyróżnić cztery zasadnicze aspekty bezpiecznego systemu informatyczne-
go [34]:

poufność (ang. secrecy),

integralność (ang. integrity),

dostępność (ang. availability),

rozliczalność (ang. accountability).

Poufność to własność systemu, która zapewnia, że informacja w żaden sposób

nie zostanie wyjawiona nieautoryzowanym użytkownikom. Jest to bardzo złożony
problem, którego rozwiązania czerpią z wielu dziedzin matematyki i informatyki.
Bezpieczeństwo dostępu do informacji realizowane jest przez mechanizmy kontroli
dostępu do zasobów (ang. access control), kontroli przepływu informacji, szyfrowa-
nia danych oraz bezpiecznej komunikacji pomiędzy elementami systemu.

Integralność to własność zapewniająca utrzymanie danych w „ważnym” stanie.

W celu zachowania integralności danych należy wykluczyć sytuacje, w których da-
ne mogą zostać zmienione w nieuprawniony lub niezgodny z założeniami działania
systemu sposób. Utrzymanie integralności staje się problemem, gdy informacja mo-
że być zmieniana przez wielu użytkowników czy procesów jednocześnie. Mechanizm

kontroli dostępu odgrywa ważną rolę w jej zapewnianiu, odpowiednio ograniczając
ilość użytkowników i procesów mających możliwość modyfikowania danych.

Dostępność jest własnością systemu, która zapewnia ciągły i niezakłócony do-

stęp użytkowników do zasobów.

Rozliczalność to pomocnicza własność systemu. Sama w sobie nie zapewnia

ochrony w sensie zapobieżenia nadużyciom, ale pozwala „po fakcie” rozpoznać, ja-
kiego typu działania zostały podjęte i kto jest za nie odpowiedzialny. W ten sposób
pełni ona funkcję prewencyjną, bowiem świadomość dużego ryzyka wykrycia od-
strasza wielu potencjalnych intruzów. Ta usługa opiera się głównie na prowadzeniu
przez system procedur rozliczania i monitorowania podejmowanych działań.

Środowisko komputerowe (system operacyjny, sieć komputerowa) może być ro-

zumiana jako zbiór zasobów dzielonych przez działające w systemie procesy [51].
Zbiór ten zawiera zarówno zasoby sprzętowe (pamięć systemu, pamięć dyskowa,
urządzenia I/O) jak i programowe (programy, pliki danych). Procesy (działające
programy) wykorzystują zasoby w trakcie swojego działania. Z punktu widzenia
bezpieczeństwa, głównym zadaniem systemu operacyjnego jest więc kontrolowanie,
które procesy mogą mieć dostęp do jakich zasobów.

W podobny sposób można analizować rozproszone systemy komputerowe, w któ-

rych dane są przechowywane w różnych hostach a wymiana informacji odbywa się
poprzez sieć. Tu również za jeden z najważniejszych z punktu widzenia bezpieczeń-
stwa mechanizmów należy uznać kontrolę dostępu do zasobów [40].

W celu teoretycznej analizy interakcji pomiędzy procesami i zasobami wprowa-

dzimy następujące określenia:

Definicja 1.1

Obiektami systemu (ang. objects) nazywamy elementy zachowujące się w sposób
pasywny. Przez zachowanie pasywne rozumiemy, że dany obiekt systemu może gro-
madzić dane, uwidaczniać je, ale sam obiekt nie podejmuje żadnych akcji.

Przykładem obiektów pasywnych są np. pliki z danymi. Obiekty oznaczać bę-

dziemy przez o, o

, . . .

Definicja 1.2

Podmiotami (ang. subjects) systemu nazywamy elementy systemu zachowujące się
w sposób aktywny. Zachowanie aktywne polega na przekształcaniu informacji, zmie-
nianiu stanu obiektów pasywnych i tworzeniu nowej informacji w systemie.

Przykładem podmiotów w systemie są procesy (uruchomione programy), często

reprezentujące pracujących w systemie użytkowników. Podmioty oznaczać będziemy
przez s, s

, s

, . . .

Zmiana stanu obiektów pasywnych przez aktywne odbywa się np.

gdy pracujący program przekształca dane wejściowe i oblicza wyniki zapisując je w
nowym obiekcie. Zauważmy, że jedynym sposobem wprowadzenia do systemu nowej
informacji jest pobranie jej z zewnątrz (od użytkownika bądź z innego źródła).

Zbiór wszystkich podmiotów rozważanego systemu będziemy oznaczać przez S,

natomiast zbiór wszystkich obiektów przez O. Warto zauważyć, że każdy podmiot
jest jednocześnie obiektem systemu, tzn. S ⊆ O, gdyż aktywny podmiot również
zawiera w sobie informację, którą może pobrać inny podmiot (czego przykładem
jest np. komunikacja międzyprocesowa [19]).

Celem wprowadzania mechanizmu kontroli dostępu jest to, by podmioty mogły

uzyskiwać różne rodzaje dostępu do obiektów. Opisywane jest to poprzez zbiór praw
dostępu jakie ma dany podmiot do obiektu.

Definicja 1.3
Pojedyncze (w sensie niezależności od innych) możliwe do uzyskania prawa jakie mo-
że posiadać podmiot do obiektu będziemy nazywać prawami rodzajowymi i oznaczać
przez r

, r

, . . .

, a ich zbiór przez R.

Rodzaj dostępu podmiotu do obiektu jest określany zazwyczaj przez pewien pod-
zbiór R ⊆ R. Przykładem zbioru możliwych praw może być zbiór R = {r, w, x}
gdzie r oznacza prawo czytania, w prawo pisania, x prawo uruchomienia programu
zawartego w obiekcie. Przykładem zbioru praw może być np. R = {r, x}.

Podmioty

Mechanizm

kontroli dostêpu

Obiekty

Rysunek 1.1. Mechanizm kontroli rozstrzyga o przyznaniu bądź odmowie dostępu
do danych

Interakcje pomiędzy elementami składowymi systemu oraz rolę mechanizmu kon-

troli dostępu ilustruje rysunek 1.1. W trakcie pracy systemu podmioty występują z
żądaniem odpowiedniego rodzaju dostępu do zasobów (obiektów). Mechanizm kon-
troli na podstawie ustalonych zasad oraz tego kto, jakiego rodzaju i do czego żąda
dostępu przyznaje go bądź też nie. Zasady według których powinien działać mecha-
nizm wynikają z obowiązującej w systemie polityki bezpieczeństwa.

1.2

Polityka bezpieczeństwa a mechanizm kontro-

li dostępu

W przypadku systemu informatycznego operującego na wrażliwych danych, z któ-
rego korzysta wiele osób, konieczne jest precyzyjne ustalenie zasad postępowania
wszystkich stron uczestniczących w przetwarzaniu informacji tak, aby w systemie
nie mogło nastąpić działanie, które naruszyłoby bezpieczeństwo informacji. Reali-
zowane jest to poprzez określenie polityki bezpieczeństwa.

Definicja 1.4

Polityką bezpieczeństwa nazywamy zbiór reguł postępowania obowiązujących wszyst-
kich użytkowników i elementy składowe systemu informatycznego, który zapewnia
bezpieczeństwo informacji przetwarzanych i gromadzonych w tym systemie.

Polityka bezpieczeństwa określa, które działania w systemie są legalne. Jest to

więc określenie wymagań co do bezpieczeństwa na najwyższym poziomie abstrakcji.
Wymagania te są uszczegóławiane na niższych poziomach. Obrazuje to rysunek 1.2.

polityka bezpieczeñstwa

modele

kontroli dostêpu

modele

nieinterferencji

modele

komunikacji

implementacje

weryfikacja

projektowanie

Rysunek 1.2. Zależności pomiędzy polityką a modelami bezpieczeństwa

Można więc powiedzieć, że na poziomie polityki bezpieczeństwa ustanawiane są

cele a modele są konkretnym rozwiązaniem, na którym sprawdzić można, czy dany
mechanizm kontroli dostępu ma pożądane własności. Ostatecznie, wymodelowany
i zweryfikowany pod kątem zgodności z założeniami polityki bezpieczeństwa mecha-
nizm jest implementowany w postaci rozwiązań programowych bądź sprzętowych.
Widać stąd, że teoretyczna analiza własności poszczególnych modeli mechanizmów
kontroli dostępu jest jednym z kluczowych zadań w procesie budowania zaufanego
systemu informatycznego.

1.3

Bezpieczeństwo a funkcjonalność systemu

Jednym z najważniejszych aspektów analizowanych przy projektowaniu systemu
informatycznego jest bezpieczeństwo. Jednak dążenie do bezpieczeństwa nie jest
w praktyce nieograniczone, gdyż drugim fundamentalnym wyznacznikiem jakości są
możliwości i wygoda użytkowania, a więc funkcjonalność systemu. Zazwyczaj obie
te cechy ograniczają się nawzajem, systemy w których użytkownik posiada duże
możliwości nie są tak bezpieczne jak te, w których uprawnienia są starannie dobie-
rane. Systemy zapewniające wysokie bezpieczeństwo informacji najczęściej nie są
tak wygodne i ich możliwości są zazwyczaj mocno ograniczone.

Wielkim wyzwaniem jest więc projektowanie i tworzenie systemów, w których

konflikt pomiędzy bezpieczeństwem a funkcjonalnością jest możliwie zminimalizo-
wany. Oczywiście nie jest możliwe całkowite wyeliminowanie wpływu założonego
wysokiego stopnia bezpieczeństwa informacji na inne aspekty jego działania, gdyż
często z samej definicji niektóre wygodne dla użytkowników rozwiązania są nie do
przyjęcia w bezpiecznym systemie. Należy jednak zwracać uwagę, czy teoretycznie
wypracowane ograniczenia zaimplementowane w systemie nie stanowią poważnego
czynnika zmniejszającego ergonomię pracy użytkowników.

Problemem bezpośrednio związanym z funkcjonalnością systemu jest jego ska-

lowalność. System powinien mieć możliwość dopasowania do rosnącej ilości danych
i użytkowników. Powyżej pewnego progu złożoności jednoosobowy nadzór nad syste-
mem staje się niemożliwy. Dlatego też oprócz wymaganego poziomu bezpieczeństwa
ważnym czynnikiem jest też możliwość zdecentralizowanego zarządzania i nadzoro-
wania systemu.

Rozdział 2

Uznaniowa kontrola dostępu

Modele z uznaniową kontrolą dostępu (ang. discretionary access control) pozwala-
ją właścicielowi obiektu na decydowanie o tym, komu przyznać prawa dostępu do
niego. Z tego też powodu stosuje się je często w praktyce. Jednak mają one pew-
ne istotne ograniczenia dotyczące możliwego do osiągnięcia poziomu zabezpieczenia
systemu przed przeciekiem informacji, dlatego w szczególnie wrażliwych systemach
ich stosowanie może być niewskazane. W rozdziale tym zostaną rozważone teore-
tyczne aspekty bezpieczeństwa samego modelu rzutujące oczywiście na praktyczne
jego zastosowania.

2.1

Ogólny model macierzy dostępu

Podstawą tego modelu opracowanego przez Lampsona [33] i rozbudowanego na-
stępnie przez Grahama i Denning [21] jest macierz, której wiersze są indeksowane
poszczególnymi podmiotami s ∈ S, zaś kolumny - obiektami o ∈ O. Każdy element
macierzy M(s, o) zawiera zestaw praw, jaki przysługuje podmiotowi s do obiek-
tu o. Jeśli więc zbiór możliwych praw oznaczymy jako R, to macierz dostępu jest
odwzorowaniem

: S × O → 2

które każdej parze (s, o) przyporządkowuje pewien podzbiór R

⊂ R

. Zawartość

macierzy M (a więc postać odwzorowania) nazywana jest stanem ochrony systemu.
Koncepcję macierzy dostępu ilustruje rysunek 2.1 Do modyfikacji wyglądu macierzy
dostępu służy określony zestaw komend takich jak

Create object

(o) - tworzy nowy obiekt o i dodaje odpowiednią kolumnę do

macierzy P

proces1

proces2

plik2

drukarka

plik1

proces1

proces2

rwxo

rwx

proces3

Rysunek 2.1. Przykładowa macierz dostępu

Create subject

(s)- tworzy nowy podmiot s i dodaje odpowiadającą jemu

kolumnę (bo podmiot jest również obiektem) oraz pusty wiersz w macierzy P

Grant permission

(r,s,o) - daje podmiotowi s prawo r ∈ R do obiektu o przez

dodanie do P [s, o] prawa r

Delete permission

(r,s,o) - odbiera podmiotowi s prawo r ∈ R do obiektu o

poprzez odjęcie prawa r z elementu macierzy P [s, o].

Transfer permission

(r,s,o) - polecenie to wywołane przez jakiś podmiot sys-

temu przekazuje swoje prawo r do obiektu o innemu podmiotowi s. Jest to
możliwe wtedy, gdy podmiot wywołujący polecenie ma możliwość przekazania
tego prawa.

Szczególną rolę pełni w tym modelu prawo własności (ang. own). Podmiot po-

siadający prawo własności do obiektu może bowiem decydować o przyznawaniu
i odbieraniu praw innym podmiotom oraz przekazywaniu uprawnień. Prawo wła-
sności przysługuje twórcy obiektu. W niektórych wersjach modelu nie da się tego
zmienić, w innych wariantach dopuszczalne są polecenia które transferują również
prawo własności obiektu.

Model Lampsona był pierwszym modelem formalnym, wyrosłym z praktyki in-

żynierii systemów operacyjnych. Dalsze prace doprowadziły do powstania bardziej
rozbudowanych i zaawansowanych modeli bazujących jednakże na podstawowym
modelu macierzy dostępu.

2.2

Model Harrisona – Ruzzo – Ullmana i nieroz-

strzygalność problemu przecieku praw

Rozszerzenie i sformalizowanie modelu macierzy dostępu przedstawili Harrison, Ruz-
zo i Ullman w pracy [26]. Model ten nazwany modelem Harrisona–Ruzzo–Ullmana
(w skrócie modelem HRU) jest jednym z podstawowych modeli systemów z uznanio-
wą kontrolą dostępu. Jego ogromną zaletą jest fakt, że dość wiernie odpowiada on
rzeczywistym systemom kontroli dostępu w systemach operacyjnych a jednocześnie
jest na tyle ściśle zdefiniowany, że dzięki niemu można udowadniać bardzo interesu-
jące i ważne dla teorii bezpieczeństwa systemów fakty. Z tego też względu opiszemy
go bardziej szczegółowo.

Definicja 2.1
System ochrony (R, C) składa się ze skończonego zbioru praw rodzajowych R oraz
skończonego zbioru C poleceń postaci

command c(X

, X

, . . . , X

)

if r

∈

, X

) and r

∈

, X

) and . . . and r

∈

, X

)

then

. . .

end

Nazwa polecenia oznaczona jest przez c, zaś X

, X

, . . . , X

są jego parametrami

formalnymi. Każda operacja op

, . . . , op

jest jedną z następujących operacji ele-

mentarnych (ang. primitive operations)

enter r into (X

, X

)

delete r from (X

, X

)

create subject s

create object o

destroy subject s

destroy object o

których znaczenie zostanie zdefiniowane niżej. W powyższej definicji r, r

, . . . , r

są

prawami rodzajowymi zaś s, s

, . . . , s

i o, o

, . . . , o

oznaczają podmioty i obiekty

odpowiednio.

Definicja 2.2
Konfiguracja systemu ochrony jest trójką (S, O, P ), gdzie S jest zbiorem bieżących
podmiotów, O jest zbiorem bieżących obiektów zaś P jest macierzą dostępu, w której
każdemu podmiotowi odpowiada pewien wiersz a obiektowi kolumna.

Oczywiście S ⊆ O, gdyż każdy podmiot jest jednocześnie obiektem systemu.

Każdy element macierzy P [s, o] jest podzbiorem zbioru praw rodzajowych R. P [s, o]
zawiera informację, jakie prawa ma podmiot s do obiektu o. Zauważmy, że wiersz
P

[s, ∗] wskazuje, co podmiot s może zrobić ze wszystkimi obiektami z O (lista

możliwości) natomiast kolumna P [∗, o] wskazuje, które podmioty mają jakie prawa
do danego obiektu o (lista dostępu).

Intuicyjne znaczenie operacji elementarnych odpowiada dokładnie ich nazwom,

jednak do celu analizy potrzebne jest formalne zdefiniowanie ich wpływu na macierz
dostępu.

Definicja 2.3
Niech (S, O, P ) i (S

, O

, P

) będą konfiguracjami systemu ochrony (R, C) i niech

będzie operacją elementarną. Wówczas

(S, O, P ) ⇒

, O

, P

)

gdy

(1) operacją op jest enter r into (s, o) i

= S, O

= O, s ∈ S, o ∈ O i

, o

] = P [s

, o

] dla (s

, o

) 6= (s, o) i

[s, o] = P [s, o] ∪ {r}

(2) operacją op jest delete r from (s, o) i

= S, O

= O, s ∈ S, o ∈ O i

, o

] = P [s

, o

] dla (s

, o

) 6= (s, o) i

[s, o] = P [s, o] \ {r}

(3) operacją op jest create subject s

= S ∪ {s

}

, O

= O ∪ {s

}

[s, o] = P [s, o] dla wszystkich (s, o) ∈ S × O i

, o

] = ∅ dla wszystkich o ∈ O

[s, s

] = ∅ dla wszystkich o ∈ S

(4) operacją op jest create object o

= S, O

= O ∪ {o

}

[s, o] = P [s, o] dla wszystkich (s, o) ∈ S × O i

[s, o

] = ∅ dla wszystkich s ∈ S

(5) operacją op jest destroy subject s

(gdzie s

∈ S

) i

= S − {s

}

, O

= O \ {o

}

[s, o] = P [s, o] dla wszystkich (s, o) ∈ S

× O

(6) operacją op jest destroy object o

(gdzie o

∈ O

) i

= S, O

= O \ {o

}

[s, o] = P [s, o] dla wszystkich (s, o) ∈ S

× O

Teraz można opisać w jaki sposób komenda jest wykonywana w systemie ochrony

(R, C).

Definicja 2.4
Niech Q będzie konfiguracją systemu ochrony. Mówimy, że konfiguracja Q

jest wy-

prowadzona z Q za pomocą polecenia c postaci

command c(X

, X

, . . . , X

)

if r

∈

, X

) and r

∈

, X

) and . . . and r

∈

, X

)

then op

, . . . , op

end

i parametrów aktualnych x

, x

, . . . , x

co zapisujemy

Q `

,...,x

)

gdy Q

określone jest następująco

(1) jeżeli warunek polecenia nie jest spełniony, tzn.

∃ i ∈ {

1, . . . , k} r

∈ P

, x

]

to Q

= Q

(2) jeżeli warunek polecenia jest spełniony, wówczas musi istnieć ciąg konfiguracji

, . . . , Q

taki, że

= Q

⇒

∗

⇒

∗

. . .

⇒

∗

= Q

gdzie op

∗

oznaczają kolejne operacje elementarne op

polecenia c wykonywane

na parametrach aktualnych x

, x

, . . . , x

. Wówczas Q

= Q

Zapis

Q `

oznacza, że istnieją parametry aktualne x

, . . . , x

takie, że Q `

,...,x

)

, zaś

zapis

Q ` Q

oznacza, że w systemie ochrony istnieje polecenie c ∈ C takie, że Q `

. W końcu,

jeżeli możemy otrzymać Q

poprzez zero lub więcej powtórzeń `, zapisujemy ten

fakt jako

Q `

∗

Możemy teraz przejść do sformułowania problemu bezpieczeństwa. Załóżmy, że

system ochrony jest w jakiejś początkowej konfiguracji Q

. Chcemy wiedzieć, czy

istnieje ciąg poleceń c

, . . . , c

, który zastosowany do Q

wyprowadza inną konfi-

gurację Q taką, że istnieje pewne polecenie c ∈ C, którego wykonanie zaowocuje
wprowadzeniem prawa r w element macierzy dostępu który wcześniej nie zawierał
prawa r.

Sformalizujmy najpierw pojęcie wprowadzenia nowego prawa w element macierzy

dostępu.

Definicja 2.5
Polecenie c(X

, . . . , X

) powoduje przeciek (uwolnienie) prawa r ∈ R z konfiguracji

= (S, O, P ), jeżeli istnieją parametry aktualne x

, . . . , x

takie, że warunek pole-

cenia c wykonującego operacje elementarne op

, . . . , op

jest spełniony oraz istnieje

liczba m ∈ {1, . . . , n} i ciąg konfiguracji Q = Q

, Q

, . . . , Q

−1

= (S

, O

, P

), Q

, O

, P

) takich, że

⇒

∗

⇒

∗

. . .

⇒

∗

m−1

−1

⇒

∗

oraz

∃s ∈ S

, o ∈ O

r /

∈ P

[s, o] ∧ r ∈ P

[s, o].

Innymi słowy, w trakcie wykonywania m-tej operacji elementarnej op

dla para-

metrów aktualnych x

, . . . , x

nastąpiło dodanie prawa r dla podmiotu s do obiek-

tu o. Zauważmy, że tą operacją musi być enter r into (s, o). Zamiast o przecieku
prawa często mówi się o uwolnieniu prawa (patrz [36]). Przeciek kojarzy się bowiem

z czymś niechcianym, natomiast często chcemy przyznać pewne prawa innemu pod-
miotowi, jak dzieje się to w przypadku współdzielenia jakiegoś obiektu.

Mając definicję uwolnienia prawa, łatwo jest już zdefiniować pojęcia niebezpiecz-

nego i bezpiecznego systemu.

Definicja 2.6
Niech będzie dane pewne prawo rodzajowe r ∈ R oraz system ochrony (R, C) ma-
jący wyjściową konfigurację Q

. Mówimy, że konfiguracja Q

jest niebezpieczna ze

względu na r jeśli

(1) istnieje konfiguracja Q taka, że Q

∗

(2) istnieje polecenie c takie, że c uwalnia r z Q.

Konfiguracja jest bezpieczna ze względu na r, jeśli nie jest niebezpieczna ze względu
na r.

Przejdziemy teraz do fundamentalnego rezultatu podanego przez Harrisona w

pracy [26] pokazującego, że problem bezpieczeństwa jest nierozstrzygalny dla ogól-
nych systemów ochrony.

Twierdzenie 2.1 (Harrison et al.)
Nie istnieje algorytm rozstrzygający, czy dana konfiguracja danego systemu ochrony
jest bezpieczna ze względu na dane prawo rodzajowe.

Dowód tego twierdzenia opiera się na symulacji dowolnej maszyny Turinga przez
system ochrony (R, C) w taki sposób, by uwolnienie prawa odpowiadało przejściu
maszyny Turinga w stan końcowy, co jak wiadomo (patrz [28]) jest problemem
nierozstrzygalnym.

2.3

Wpływ ograniczeń na złożoność problemu

przecieku praw

Z twierdzenia 2.1 wynika, że dla ogólnego modelu nie da się rozstrzygać o tym,
czy konfiguracja jest bezpieczna. Naturalne jest zatem postawienie pytania o pew-
ne ograniczenia dotyczące możliwości systemu, które pozwolą na łatwiejszą analizę
problemu bezpieczeństwa.

Dla systemów w których każde polecenie wykonuje tylko jedną operację elemen-

tarną (takie systemy nazywamy monooperacyjnymi) problem bezpieczeństwa jest
łatwiejszy, o czym mówi poniższe twierdzenie.

Twierdzenie 2.2 (Harrison et al.)
Istnieje algorytm rozstrzygający, czy dany monooperacyjny system ochrony w danej
konfiguracji początkowej jest bezpieczny dla danego prawa rodzajowego.

Niestety, takie ograniczenie jest bardzo restrykcyjne i praktycznie nie może być

spełnione w rzeczywistym systemie.

Kolejną klasą systemów z ograniczeniami są systemy monotoniczne. System jest

monotoniczny jeżeli nie istnieją w nim polecenia c ∈ C używające operacji elementar-
nych destroy subject s, destroy object o i delete r from (s, o). W ogólnym
przypadku takie ograniczenie nie wpływa na złożoność problemu bezpieczeństwa
(jest on nadal nierozstrzygalny, patrz [27]), jednak gdy w części warunkowej znajdu-
je się tylko jeden test logiczny, sytuacja zmienia się według poniższego twierdzenia.

Twierdzenie 2.3 (Harrison, Ruzo)
Problem bezpieczeństwa dla monotonicznych jednowarunkowych systemów ochrony
jest rozstrzygalny.

Ograniczenia tego typu bardzo zawężają możliwości systemu, gdyż pozwalają

tylko na tworzenie nowych obiektów i dodawanie praw.

Znacznie ciekawszy z praktycznego punktu widzenia rezultat udowodnili Lipton

i Snyder w swojej pracy [38].

Twierdzenie 2.4 (Lipton, Snyder)
Problem bezpieczeństwa dla danego systemu ochrony ze skończoną ilością obiektów
jest rozstrzygalny.

Założenie o skończonej ilości obiektów w rzeczywistym systemie jest dość reali-

styczne, tak więc twierdzenie to rzuca nowe światło na problem przecieku praw.

Kolejne twierdzenie pochodzące z [26] pokazuje jednak, że nawet dla bardzo

ograniczonego modelu, w którym nie ma możliwości tworzenia nowych obiektów,
problem przecieku praw pozostaje bardzo trudny obliczeniowo.

Twierdzenie 2.5 (Harrison et al.)
Problem bezpieczeństwa dla systemów bez operacji elementarnej create jest zupeł-
ny w przestrzeni wielomianowej.

Ponieważ problemy zupełne w przestrzeni wielomianowej są problemami trudny-

mi obliczeniowo (są co najmniej tak trudne jak problemy NP-zupełne, patrz [16]),
tak więc w praktyce niemożliwe okazuje się udzielenie odpowiedzi na pytanie o bez-
pieczeństwo systemu praktycznych rozmiarów (a więc mającego tysiące obiektów)
w sensownym czasie.

Oprócz tej cechy modelu HRU uważanej za jego główny mankament należy dodać

jeszcze, że nie wszystkie polityki bezpieczeństwa bazujące na uznaniowym przydzie-
laniu praw dostępu przez właściciela daje się za jego pomocą zrealizować. Dlatego
też model ten na przestrzeni ostatnich 20 lat stał się przedmiotem intensywnych
analiz i modyfikacji. Badaczom chodziło przede wszystkim o:

wprowadzenie modyfikacji pozwalających w łatwy sposób rozstrzygać o bez-
pieczeństwie systemu

wprowadzenie nowych elementów wzbogacających model o nowe możliwości
kontroli pozwalające na realizację bardziej skomplikowanych polityk bezpie-
czeństwa.

Jednym z ciekawszych otrzymanych rezultatów jest modyfikacja modelu poprzez
dodanie typów obiektów.

2.4

Model macierzy dostępu z typami obiektów

Propozycją wysuniętą w celu poprawienia własności klasycznego modelu HRU jest
model macierzy dostępu z typami obiektów (ang. Typed Access Matrix ), w skrócie
TAM, zaproponowany przez Sandhu w [53]. Jest on bardzo podobny do modelu
HRU, dlatego w dalszym ciągu rozważań wskażemy tylko modyfikacje w stosunku
do poprzedniego modelu. Zasadnicza różnica polega na tym, że każdy obiekt ma swój
typ, określany w czasie jego tworzenia i niezmienny w ciągu istnienia obiektu (typy
są statyczne). Istnieje więc pewien skończony zbiór typów, T wraz z wyróżnionym
podzbiorem T

⊂ T

będącym zbiorem typów podmiotów oraz funkcja

: O → T

która każdemu obiektowi przyporządkowuje jego typ. Zauważmy, że funkcja okre-
ślona jest tak, by

: S → T

oraz

O\S

: (O \ S) → (T − T

)

co oznacza, że podmioty mają typy należące do podzbioru T

a „czyste obiekty”

mają typy należące do zbioru T \ T

Polecenia systemu ochrony mają następującą postać:

command c(X

: t

, X

: t

, . . . , X

: t

)

if r

∈

, X

) and r

∈

, X

) and . . . and r

∈

, X

)

then

; op

; . . .; op

end

gdzie każda z operacji op

jest jedną z operacji elementarnych postaci

enter r into [X

, X

]

create subject X

of type t

create object X

of type t

delete r from [X

, X

]

destroy subject X

destroy object X

Różnica polega na tym, że każdy parametr formalny ma swój typ, zatem polecenie
może być wykonane tylko dla parametrów aktualnych będących obiektami odpo-
wiednich typów a polecenia tworzą obiekty i podmioty określonych typów.

Monotoniczny model macierzy dostępu z typami (MTAM) różni się od poprzed-

niego tym, że nie występują w nim trzy ostatnie z wymienionych operacji które
usuwają prawa i niszczą podmioty i obiekty.

Analiza własności bezpieczeństwa tego modelu wskazuje, że trudność problemu

przecieku zależy od pewnych zależności między typami. W celu ich analizy wprowa-
dzimy następującą definicję

Definicja 2.7
Niech α będzie poleceniem zawierającym operację elementarną create z parame-
trami formalnymi (X

: t

, X

: t

, . . . , X

: t

). Mówimy, że t

jest typem potomnym

w α jeżeli w treści polecenia pojawia się jedno z poleceń

create subject X

of type t

create object X

of type t

W przeciwnym razie mówimy, że typ t

jest typem bazowym w α.

Na skutek takiego sformułowania otrzymujemy hierarchię typów dla danego sys-
temu ochrony, zależną od definicji poleceń c ∈ C. Możemy ją wyrazić za pomocą
grafu skierowanego, którego wierzchołkami są możliwe typy obiektów zaś krawędzie
wskazują na relacje typ bazowy – typ potomny. Ujmując rzecz bardziej formalnie,
możemy przedstawić następującą definicję.

Definicja 2.8

Graf tworzenia dla schematu MTAM jest skierowanym grafem o wierzchołkach ze
zbioru T oraz krawędzią z u do v wtedy i tylko wtedy, gdy u jest typem bazowym
zaś v typem potomnym.

Dzięki powyższym definicjom możemy już wyrazić własności bezpieczeństwa tych
modeli.

Twierdzenie 2.6 (Sandhu)
Problem bezpieczeństwa jest rozstrzygalny dla systemów ochrony w których graf
tworzenia jest acykliczny.

Widzimy więc, że sytuacja staje się nierozstrzygalna, gdy w grafie tworzenia poja-
wiają się cykle. Przykładowo, jeśli w jednym poleceniu typ t

występuje jako bazowy

a t

jako potomny, podczas gdy w innym poleceniu typ t

występuje jako bazowy

zaś t

jako potomny, to problem bezpieczeństwa dla systemu zawierającego takie

dwa polecenia jest już nierozstrzygalny.

Niestety, sama rozstrzygalność nie jest rezultatem zadowalającym. Okazuje się,

że problem ten jest bardzo złożony obliczeniowo o czym mówi poniższe twierdzenie.

Twierdzenie 2.7 (Sandhu)
Dla monotonicznych systemów TAM z acyklicznym grafem tworzenia problem bez-
pieczeństwa jest NP-trudny.

Z praktycznego punktu widzenia interesujące jest otrzymanie modeli dla których
ten problem jest łatwy do rozstrzygnięcia w sensie obliczeniowym. Taka propozycją
jest trójkowy MTAM, przedstawiony również w pracy [53].

Definicja 2.9

Trójkowym modelem TAM nazywamy model macierzy dostępu z typami obiektów
(TAM) w którym wszystkie polecenia mają co najwyżej trzy parametry.

Analogicznie definiujemy monotoniczną wersję trójkowego TAM, trójkowy MTAM.

Model ten nie jest żadnym ograniczeniem ogólnego modelu TAM, gdyż udowod-

nione zostało, że oba modele mają identyczną siłę wyrazu, tzn. jeśli jakąś politykę
bezpieczeństwa da się wyrazić za pomocą jednego modelu, można to też uczynić uży-
wając drugiego

. Zatem można posługiwać się jedynie modelem trójkowym. Jednak

jeżeli chodzi o trudność problemu bezpieczeństwa, to różnica jest zasadnicza. Mówi
o tym poniższe twierdzenie.

Twierdzenie 2.8 (Sandhu)
Problem bezpieczeństwa dla trójkowego monotonicznego modelu TAM posiadające-
go acykliczny graf tworzenia jest rozstrzygalny w czasie wielomianowym ze względu
na wielkość wyjściowej macierzy dostępu.

Wynika stąd, że dla takiego modelu i poprawnie dobranych poleceń systemu ochro-
ny można skonstruować efektywny algorytm który będzie rozstrzygał o możliwości
przecieku praw.

Powyższe rozważania można uogólnić, wprowadzając dynamiczne przypisywanie

typów obiektów. Badania takie przeprowadził M. Soshi, który w swojej pracy [60]
opisuje model macierzy dostępu z dynamicznymi typami obiektów (DTAM). Główną
różnicą jest to, że typy obiektów nie są statyczne, ale mogą być zmieniane za pomocą
wprowadzonych dodatkowo poleceń elementarnych służących temu celowi.

Dla tego modelu udowodniono, że rozstrzygalność problemu bezpieczeństwa uzy-

skujemy dla systemów w których graf tworzenia (nazwany tam grafem relacji typów)
jest acykliczny oraz w systemie ochrony nie występują tzw. samotne typy (ang. or-
phan types). Podobnie okazuje się, że dla systemów nie zawierających poleceń w
których występuje operacja elementarna create posiadających acykliczny graf rela-
cji typów problem bezpieczństwa pozostaje NP-trudny.

Wydaje się więc, że w przypadku macierzowej reprezentacji systemu ochrony na

wzór modelu HRU bardzo trudno jest otrzymać model w którym rozstrzyganie o
problemie przecieku nie ma dużej złożoności obliczeniowej. Stąd w ramach polityki
dobrowolnej kontroli dostępu narodziły się inne podejścia do modelowania systemu
ochrony.

Zauważmy, że nie wiadomo jednak, czy taka odpowiedniość zachodzi dla modeli w których

grafy tworzenia są acykliczne co jest używanym potem założeniem

2.5

Gramatyczne systemy ochrony

Do tej pory na model systemu ochrony patrzyliśmy jak na macierz M poddawaną
przekształceniom określanym przez polecenia systemu ochrony c ∈ C. W macierzy tej
zawarte były informacje na temat wzajemnych zależności (praw dostępu) pomiędzy
obiektami systemu.

Innym podejściem jest reprezentacja zależności pomiędzy obiektami za pomocą

grafu. Wówczas obiekty systemu są reprezentowane poprzez wierzchołki pewnego
grafu, natomiast prawom dostępu pomiędzy obiektami odpowiadają krawędzie gra-
fu. Łatwo zauważyć równoważność pomiędzy takimi przedstawieniami, gdyż grafy
mają swoją reprezentację macierzową (patrz rozdział 23 w [9]).

Poniżej przedstawiony zostanie ogólny model grafowy zaprezentowany w [37]

wraz z analizą złożoności problemów bezpieczeństwa a następnie rozważone zostaną
pewne szczególne przypadki tego modelu o szczególnie prostym do zweryfikowania
problemie bezpieczeństwa.

Niech X = {x

, x

, . . . , x

}

oznacza zbiór obiektów systemu ochrony. Każdy

obiekt ma typ będący elementem skończonego zbioru typów T = {t

, t

, . . . , t

}

istnieje więc funkcja T : X → T przyporządkowująca obiektowi jego typ. Skończony
zbiór praw rodzajowych oznaczmy przez R = {r

, r

, . . . , r

}

. Zakładamy ponadto,

że zbiory T i R są alfabetami, a więc typy t

oraz prawa r

są symbolami. Ciąg sym-

boli może być traktowany jako słowo nad odpowiednim alfabetem. W szczególności,
słowo puste oznaczamy przez .

Definicja 2.10

Konfiguracją systemu ochrony nazywamy skierowany graf etykietowany G = (X, E)
gdzie X jest zbiorem wierzchołków grafu z których każdy reprezentuje obiekt sys-
temu, E ⊆ X × X jest zbiorem krawędzi zaś funkcja w : E → R jest funkcją
etykietującą krawędzie.

Każdemu wierzchołkowi grafu odpowiada jego typ, będziemy to oznaczali pisząc

; t). Jeśli (x

, x

) ∈ E oznacza to, że w grafie istnieje krawędź z wierzchołka x

. Krawędzie wraz z ich etykietami będziemy zapisywać jako (x

, x

; r). Przykłado-

wy graf ochrony pewnego systemu ilustruje rysunek 2.2.

Konfiguracja systemu ochrony opisuje chwilowy stan w jakim znajduje się sys-

tem. Do pełnego opisu potrzebne są jeszcze reguły określające w jaki sposób może
zmieniać się stan systemu. W modelu macierzowym były to polecenia, w modelu
grafowym ich rolę pełnią reguły przejścia określające jak zmienia się znakowanie

krawędzi grafu na skutek przyznawania lub odbierania praw.

Za pomocą poniższej definicji określamy, które obiekty mogą otrzymać prawo α

do pewnego ustalonego obiektu systemu.

Definicja 2.11
Załóżmy, że mamy dany system ochrony w konfiguracji reprezentowanej przez graf
G

= (X, E). Mówimy, że

może-α x

gdy istnieje skończony ciąg reguł przejścia taki, że po ich zastosowaniu wierzchołek
x

jest połączony z wierzchołkiem x

za pomocą krawędzi z etykietą α ∈ R, czyli

, x

) ∈ E ∧ w((x

, x

)) = α

Zauważmy, że mając powyższą definicję w alternatywny sposób możemy sformu-

łować problem bezpieczeństwa określony w definicji 2.5:

Mając dany system ochrony G i dwa obiekty x

oraz x

jeżeli przyznamy

obiektowi x

prawo α do obiektu x

czyli spowodujemy, że

((x

, x

)) = α

jakie inne obiekty x ∈ X mogą uzyskać prawo α do obiektu x

, czyli dla

jakich x ∈ X zachodzi

może-α y

Jak pokazało twierdzenie 2.1 w ogólnym przypadku jest to problem nierozstrzy-

galny. Jednak bazując na grafowej reprezentacji systemu ochrony można wprowadzić

plik2

drukarka

plik1

plik3

proces1

proces2

rwx

Rysunek 2.2. Graf opisujący konfigurację systemu ochrony

specjalne klasy systemów ochrony dla których problem bezpieczeństwa jest rozstrzy-
galny w czasie wielomianowym a nawet liniowym ze względu na wielkość grafu G.

Dla jasności dalszego wywodu wprowadzimy pojęcie etykiety ścieżki w grafie oraz

przypomnimy za [39] definicję gramatyki.

Definicja 2.12
Niech s = (x

, x

, . . . , x

), gdzie (x

i−1

, x

) ∈ E ∀i ∈ {1, . . . , k} będzie ścieżką

w grafie G = (X, E) z funkcją etykietowania krawędzi w : E → R. Wówczas etykietą
ścieżki nazywać będziemy

)||w(x

)|| . . . ||w(x

czyli słowo powstałe z konkatenacji etykiet krawędzi należących do ścieżki s.

Definicja 2.13

Gramatyką nazywamy uporządkowaną czwórkę postaci

= (V ar, T er, P ro, St),

gdzie

V ar

jest skończonym zbiorem zmiennych,

T er

jest skończonym zbiorem symboli terminalnych, przy czym V ar∩T er = ∅,

P ro

jest skończonym podzbiorem (V ar ∪ T er)

(V ar ∪ T er)

∗

nazywanym

zbiorem produkcji; piszemy v 7→ u jeżeli v ∈ (V ar ∪ T er)

, u ∈ (T er ∪ V ar)

∗

oraz (v, u) ∈ P ro,

St ∈ V ar

jest symbolem początkowym.

Każda gramatyka G = (V ar, T er, P ro, St) generuje język nad alfabetem T er, będący
podzbiorem T er

∗

. Język generowany przez gramatykę G będziemy oznaczać przez

(G).

Definicja 2.14
Grafowy system ochrony jest nazywany gramatycznym, jeżeli dla każdego prawa
r ∈ R

istnieje gramatyka G

= (V ar

, T er

, P ro

, St

) taka, że dla każdych dwóch

wierzchołków grafu ochrony x, y ∈ X są one połączone scieżką, której oznakowanie
jest w L(G

) wtedy i tylko wtedy, gdy x może-α y.

Jako przykład rozważymy za [37] i [36] system ochrony nazwany ogólnym sys-

temem przemieszczania krawędzi. Skonstruujemy dla niego odpowiednią gramatykę
i wykażemy, że jest to system gramatyczny. Reguły przejścia dla tego przykładowego
systemu mają następującą postać.

Jeżeli x

, x

∈ X

są wierzchołkami grafu G o typach t

, t

odpo-

wiednio, oraz istnieją etykietowane krawędzie (x

, x

; r

) i (x

, x

; r

), to

zastosowanie jedynej w tym systemie reguły przejścia daje nowy graf
ochrony G

= (X, E

) taki, że E

= E ∪ (x

, x

) przy czym w((x

, x

)) =

Mając dany powyższy ogólny system przemieszczania wierzchołków gramatykę

= (V ar, T er, P ro, St) konstruujemy następująco. Jeśli pomiędzy wierzchołkami o

typach t i t

może być prawo r, do zbioru zmiennych musimy dodać (t, r, t

). Zatem

można przyjąć, że

V ar

= T × R × T

Dla każdej zmiennej A = (t, r, t

) tworzymy odpowiadający jej symbol terminalny

= [t, r, t

]. (Zauważmy, że różne nawiasy mówią, że V ar ∩ T er = ∅). Symbol po-

czątkowy nie będzie określony, gdyż de facto rozważamy klasę gramatyk różniących
się tylko możliwymi symbolami startowymi. W końcu definiujemy produkcje tej gra-
matyki. Dla każdej reguły takiej jak opisanej powyżej dodajemy produkcję postaci
A → BC

czyli

, r

, t

) → (t

, r

, t

)(t

, r

, t

)

Odpowiadają one znaczeniu reguły przejścia. Ostatecznie, dla każdej zmiennej A =
(t, r, t

) dopisujemy produkcję

A → a

gdzie a = [t, r, t

Zauważmy, że zbiory V ar i T er są skończone (co wynika ze skończoności T i R)

natomiast wszystkie produkcje są postaci A → BC lub A → a gdzie A, B, C ∈
V ar

i a ∈ T er. Takie klasy gramatyk nazywamy gramatykami w postaci normalnej

Chomsky’ego i są to gramatyki bezkontekstowe [28].

Jeżeli teraz oznaczymy przez L(A) język generowany przez gramatykę G =

(V ar, T er, P ro, A), gdzie A ∈ V ar, otrzymujemy następujące stwierdzenie, które
mówi, że pewien obiekt może uzyskać prawo do innego tylko wtedy, gdy jest z nim
połączony ścieżką o oznakowaniu będącym słowem języka generowanego przez od-
powiednio określoną gramatykę.

Twierdzenie 2.9 (Leiss)
Załóżmy, że w systemie ochrony istnieją dwa obiekty, v typu s i w typu t odpowied-
nio. Wówczas v może-r w wtedy i tylko wtedy, gdy w grafie ochrony istnieje ścieżka
pomiędzy s i w, której oznakowanie jest słowem języka L(A) gdzie A = (s, r, t).

Mając więc gramatyczny system ochrony, w celu sprawdzenia czy pewien dany

obiekt może uzyskać prawo do innego, należy wygenerować odpowiednią gramatykę
G

, a następnie dla każdej ścieżki łączącej wierzchołki grafu ochrony odpowiadające

badanym obiektom stwierdzić, czy oznakowanie ścieżki jest słowem języka L(A).
Algorytm znajdowania etykiet ścieżek dla grafu skierowanego opisany jest w [9]
i ma on złożoność Θ(n

), gdzie n oznacza liczbę wierzchołków grafu. W następnym

kroku dla wybranej etykiety ścieżki rozstrzygamy, czy jest ona słowem języka L(A).
Można tego dokonać za pomocą algorytmu Cocke’a–Youngera–Kasamiego [64]

czasie O(m

) gdzie m jest długością etykiety ścieżki. Ponieważ m ¬ n − 1, gdyż

w grafie acyklicznym najdłuższa (w sensie ilości zawartych krawędzi) ścieżka może
mieć co najwyżej n − 1 krawędzi, problem bezpieczeństwa dla pojedynczego obiektu
w gramatycznym systemie ochrony można oszacować jako O(n

W rzeczywistości, w pracy [37] pokazano znacznie mocniejszy rezultat. Jeżeli

przez rozszerzony problem bezpieczeństwa będziemy rozumieć globalne pytanie jakie
prawa mogą stać się dostępne dla obiektów systemu po dodaniu pewnego prawa
jakiemuś obiektowi, złożoność obliczeniową tego problemu podaje poniższe twier-
dzenie.

Twierdzenie 2.10 (Lipton)
Rozszerzony problem bezpieczeństwa dla ogólnego systemu przemieszczania wierz-
chołków może być rozstrzygnięty w czasie O(n

2.81

) gdzie n oznacza ilość obiektów

systemu ochrony.

Dowód polega na przedstawieniu grafu ochrony w postaci macierzy górnie trój-

kątnej przez wprowadzenie „odwrotnych” praw a następnie na znalezieniu z wyko-
rzystaniem algorytmu podanego przez Valiant’a [62] przechodniego domknięcia tej
macierzy względem „mnożenia macierzy”, w którym role dodawania skalarów pełni
operacja sumowania zbiorów a rolę mnożenia skalarów pełni redukcja z wykorzysta-
niem produkcji (określona jako BC = A ⇐⇒ (A, BC) ∈ P ro).

istnieją lepsze algorytmy, np. algorytm Grahama, Harrisona, Ruzzo [22] ma złożoność

O(n

/ log n) ale nie wpływa to na powyższe oszacowanie całkowitego czasu działania

Jednak dla pewnych szczególnych klas gramatycznych systemów ochrony, w któ-

rych otrzymana gramatyka jest gramatyką regularną, problem bezpieczeństwa jest
jeszcze prostszy do badania. Mówi o tym poniższe twierdzenie.

Twierdzenie 2.11 (Leiss)
Dla regularnych systemów ochrony problem bezpieczeństwa jest rozstrzygalny w
czasie liniowym ze względu na ilość obiektów w systemie.

Dowód opiera się na obserwacji, że jeśli gramatyka jest regularna, to istnieje

automat skończony rozpoznający język generowany przez tą gramatykę a jego wiel-
kość (liczebność zbioru Q stanów automatu, oznaczmy ją przez c) nie zależy od
ilości n obiektów w systemie. Konstruowany jest nowy graf G

= (X × Q, E

) mają-

cy cn wierzchołków, który ma krawędź od (x

, q

) do (x

, q

) wtedy i tylko wtedy, gdy

pomiędzy obiektami x

i x

istnieje krawędź z etykietą r i automat w stanie wejścio-

wym q i symbolu r przechodzi w stan q

. Załóżmy że chcemy rozstrzygnąć problem

bezpieczeństwa dla wierzchołka x ∈ X. Konstrukcję przeprowadzamy poprzez prze-
szukiwanie w głąb grafu G, czego dokonać można w czasie O(e), gdzie e jest ilością
krawędzi grafu G, jednocześnie zaznaczając te wierzchołki G

dla których automat

znalazł się w stanie końcowym. Odpowiadające im wierzchołki grafu G oznaczają
obiekty, które mogą otrzymać prawa.

Jest to bardzo korzystny rezultat, gdyż czas potrzebny na przeanalizowanie bez-

pieczeństwa jest niewielki nawet dla bardzo dużych systemów.

Problemem projektowym jest jednak fakt, że pytanie, czy dana gramatyka bez-

kontekstowa generuje język regularny jest nierozstrzygalne, nawet dla gramatyk w
postaci normalnej Chomsky’ego [28]. Dlatego też, aby uniknąć bezsensownych po-
szukiwań, rozważa się szeroką klasę systemów będących podzbiorem regularnych
systemów ochrony o specjalnej własności, tzw. systemów niedyskryminujących. Nie-
formalnie, gramatyczny system ochrony jest niedyskryminujący, jeżeli wszystkie re-
guły przejścia zdefiniowane w systemie mają postać

jeżeli obiekt x ma prawo r do obiektu y i obiekt y ma dowolne prawo r

do obiektu z, wówczas x może uzyskać prawo r

do z

a więc reguły nie dyskryminują żadnych praw r

mogących wystąpić na drugiej

krawędzi. Formalnie, system definiujemy jako niedyskryminujący, jeżeli posiada on
niedyskryminującą gramatykę, którą określa się za pomocą warunków nałożonych
na postać produkcji i zmiennych.

Dla niedyskryminujących gramatyk prawdziwe jest następujące twierdzenie, bę-

dące powodem ich określenia.

Twierdzenie 2.12 (Leiss)
Język generowany przez dowolną gramatykę niedyskryminującą jest regularny.

Dzięki temu, w celu konstrukcji regularnego systemu ochrony definiujemy reguły pro-
dukcji tak, aby były one zgodne z definicją gramatyki niedyskryminującej. Wówczas
powyższe twierdzenie zapewnia nas, że języki generowane przez takie gramatyki są
regularne

, a więc istnieje algorytm rozstrzygający w czasie liniowym problem bez-

pieczeństwa. W następnym podrozdziale przedstawimy powszechnie znany przykład
grafowego modelu systemu ochrony, który jak się okazuje jest systemem regularnym
a jego gramatyka jest gramatyką niedyskryminującą.

2.6

Model „przejmij–przekaż”

Model „przejmij–przekaż” (ang. take–grant) przedstawiony został przez Grahama
i Denning w pracy [21] oraz przez A. Jones w jej pracy doktorskiej [29] i doskonalony
w wielu późniejszych publikacjach. Przedstawimy tu za [36] jego prostszą wersję. Jest
to model grafowy, w którym występują dwa standardowe typy wierzchołków grafu
ochrony – obiekty i podmioty, tak więc T = {s, o}. W systemie zdefiniowane są prawa
przejmij (czytaj) - t i przekaż (pisz) - g, zatem R = {t, g, tg} gdzie tg oznacza prawo
do przejmowania i przekazywania jednocześnie oraz trzy reguły przejścia nazywane
przejmij, przekaż i utwórz. Jeżeli przez ρ ∈ R oznaczymy dowolne prawo to ich
znaczenie jest następujące:

przejmij: niech x będzie podmiotem mającym prawo t do y i niech y ma
dowolne prawo ρ do z; wówczas na mocy reguły przejmij x uzyskuje to prawo
ρ

do z, czyli

(x) = s ∧ (x, y; t) ∈ E ∧ (y, z; ρ) ∈ E =⇒ E := E ∪ (x, z; ρ),

przekaż: niech x będzie podmiotem mającym prawo g do y i niech x ma
dowolne prawo ρ do z; wówczas na mocy reguły przekaż y uzyskuje prawo ρ
do z, czyli

(x) = s ∧ (x, y; g) ∈ E ∧ (x, z; ρ) ∈ E =⇒ E := E ∪ (y, z; ρ),

warto zwrócić uwagę, że sama gramatyka nie musi być regularna [36]

utwórz: niech x będzie podmiotem; dzięki regule utwórz x może utworzyć

nowy podmiot do którego ma prawa t, g.

Graficznie reguły przejmij i przekaż przedstawione są na rysunku 2.3.

przejêcie
prawa

przekazanie
prawa

Rysunek 2.3. Przejęcie i przekazanie prawa % przed podmiot x.

Widać, że reguły przejścia mają postać niedyskryminującą, a zatem w powyż-

szym systemie na mocy twierdzeń 2.12 i 2.11 problem bezpieczeństwa jest rozstrzy-
galny w czasie liniowym względem rozmiaru grafu ochrony. Dokładne uzasadnienie
wraz z wyprowadzeniem wyrażenia regularnego odpowiadającego gramatyce tego
systemu można znaleźć w [36].

Model „przejmij-przekaż” może mieć również bardziej skomplikowane formy.

Zbiór praw może być szerszy, wzbogacony o dodatkowe uprawnienia, nadal jednak
kluczowe prawa to t-take i g-grant, pozwalające na przekazywanie i przejmowanie
pozostałych praw takich jak pisanie, czytanie, modyfikowanie, dopisywanie i inne.

Ponieważ model ten powstał niezależnie od teorii gramatycznych systemów och-

rony, ma on również niezależne uzasadnienie kwestii dotyczących bezpieczeństwa.
Wprowadza się w nim charakterystyki pewnych układów etykietowań ścieżek (mó-
wiąc o t-g ścieżkach, t-g półścieżkach, mostkach i przęsłach początkowych i końco-
wych gdy ścieżki łączą wierzchołki odpowiednich typów i mają etykietowania od-
powiadające pewnym wyrażeniom regularnym) a następnie dzięki nim formułuje
się problem rozstrzygania kiedy x może-α y. Analizę tego typu można znaleźć na
przykład w książce [13]. Oczywiście przy takim podejściu również wykazuje się, że
problem bezpieczeństwa ma liniową złożoność ze względu na wielkość wyjściowego
grafu ochrony [30].

W modelu „przejmij–przekaż” analizuje się również problem kradzieży praw.

Kradzież praw polega na takim przekazaniu swoich praw przez podmiot x, by w
rezultacie (po wykonaniu pewnej serii reguł przejścia być może przez kilka współ-
pracujących ze „złodziejem” obiektów) móc otrzymać prawo α do obiektu y. Jego

a ściślej zlecić systemowi operacyjnemu utworzenie

analizę oraz przedstawiony poniżej warunek konieczny i wystarczający na kradzież
praw zawarto w [59].

Twierdzenie 2.13 (Snyder)
Niech system ochrony będzie reprezentowany przez graf G. Wówczas podmiot x
może ukraść prawo r do obiektu y gdy spełnione są jednocześnie trzy warunki:

w G nie ma krawędzi z x do y etykietowanej r

istnieje podmiot x

taki, że x

= x albo x

jest połączony przęsłem początko-

wym z x (tzn. istnieje ścieżka od x

do x której etykietą jest słowo odpowia-

dające wyrażeniu regularnemu −

→

∗

istnieje wierzchołek s i krawędź (s, y) z etykietą r

może-t s jest prawdą

Dzięki powyższemu twierdzeniu można sprawdzić, czy w systemie ochrony na skutek
współdziałania innych podmiotów możliwe jest uzyskanie prawa r przez podmiot x.
Przykład sytuacji w której podmiot x wykrada od s prawo r do obiektu y przy
udziale konspiratora x

przedstawia rysunek 2.4.

kradzie¿ prawa r

Rysunek 2.4. Podmiot x kradnie prawo do y przy współudziale x

Jednak niemożność pozyskania prawa np. odczytu do pewnego obiektu nie ozna-

cza, że podmiot nie jest w stanie poznać informacji zawartych w tym obiekcie. Moż-
liwy jest bowiem niejawny przepływ informacji. Najprostszą taką sytuację ilustruje
rysunek 2.5, na którym dane z obiektu z dostają się do x pośrednio poprzez odczy-
tanie ich przez y, do którego z kolei jawne prawo czytania ma podmiot x.

Dlatego też oprócz opisanych powyżej właściwości może dzielić i może ukraść

odnoszących się do jawnego zdobycia odpowiednich praw, trzeba też analizować

Rysunek 2.5. Niejawny przepływ informacji z obiektu z do x poprzez y

przepływ informacji bez uzyskania jawnych praw dostępu. Analizę tego typu przed-
stawiono w [4], gdzie wyróżniono cztery reguły (nazwane regułami de facto), w któ-
rych informacja może przepłynąć z jednego wierzchołka do innego bez jawnego prawa
pozwalającego na tego typu operację. Ciekawe rozwinięcie badań nad konspiracją
i niejawnym przepływem informacji w modelu „przemij-przekaż” podał w swojej pra-
cy [5] Bishop. Podaje on ilości „agentów” którzy muszą współdziałać aby możliwe
było poznanie pewnej informacji. Jako przykład praktyczny modelowaniu poddana
została sieć lokalna w której wymiana informacji pomiędzy hostami dokonywana jest
za pomocą ftp a następnie pokazuje, jak odpowiedzieć na pytanie, czy pewne tajne
pliki które znalazły się w jednym z komputerów mogły zostać pobrane za pomocą
serii transferów ftp i ile osób musiało w tym współuczestniczyć.

2.7

Podsumowanie cech uznaniowej kontroli dos-

tępu

Na podstawie przedstawionej powyżej wielostronnej analizy modeli uznaniowej kon-
troli dostępu można wskazać jej cechy charakterystyczne, które mogą być wskazówką
przy projektowaniu systemu komputerowego. Z podstawowego założenia, zgodnie z
którym właściciele mogą według swojego uznania zmieniać prawa do swojej infor-
macji zawartej w obiektach systemu, wynika ogromna trudność kontroli nad wraż-
liwymi danymi systemu. Jak zostało to pokazane, w wielu przypadkach niemożliwe
jest stwierdzenie, czy dane działania użytkownika nie spowodują zagrożenia dla po-
ufności danych, niemożliwe jest też śledzenie rozprzestrzeniania się informacji. W
sytuacjach, gdy teoretyczny model pozwala na pewną kontrolę, w praktyce okazuje
się on zbyt skomplikowany w implementacji.

Wydaje się, że największy potencjał wykazuje modelowanie oparte na grama-

tycznych systemach ochrony, w szczególności model „przejmij–przekaż” na które-

go bazie być może można tworzyć bardziej zaawansowane modele pozwalające na
uwzględnienie dodatkowych czynników narzucanych przez politykę bezpieczeństwa,
nie tracąc szybkości weryfikacji potencjalnie niebezpiecznych dla poufności informa-
cji stanów systemu tym bardziej, że z pomocą mogą przyjść narzędzia z dziedziny
teorii języków i kompilatorów. Być może znane i doskonalone przez lata algorytmy
rozpoznawania konstrukcji języka czy parsingu będą mogły znaleźć nowe zastoso-
wanie w weryfikacji stanu systemu ochrony.

Z punktu widzenia praktyka, systemy z uznaniową kontrolą dostępu mogą być

stosowane w środowiskach w których nie przetwarza się wrażliwej informacji a użyt-
kownicy są na tyle świadomi i odpowiedzialni, by nie wykonywać zbędnych i poten-
cjalnie niebezpiecznych operacji udostępniania swoich zasobów. Oznacza to jednak,
że uznaniowa kontrola dostępu nie jest dobrym rozwiązaniem w większości istnieją-
cych obecnie systemów komputerowych.

Rozdział 3

Obowiązkowa kontrola dostępu

W systemach, w których konieczna jest stała kontrola nad rozprzestrzenianiem się
informacji, często stosowana jest polityka obowiązkowej kontroli dostępu. Ideą leżą-
cą u podstaw tego typu modeli jest założenie, że informacja może przepływać „w
jednym kierunku”, tzn. od obiektów o niższej klasyfikacji tajności do obiektów o wyż-
szym stopniu tajności. Dzięki temu żadna tajna informacja nie zostanie przekazana
do obiektu o mniejszym stopniu tajności. Widać, że decyzja o tym, jaka jest klasy-
fikacja obiektu czy podmiotu musi być określona „odgórnie” a ponadto użytkownik
nie ma możliwości modyfikacji swoich uprawnień. Stąd nazwa tego typu systemów –
obowiązkowa kontrola dostępu (ang. mandatory access control). Ze względu na po-
dejście do analizy bezpieczeństwa nazywa się je także modelami kontroli przepływu
informacji, chociaż pojęcie to jest szersze, gdyż obejmuje nie tylko problem dostępu
do danych, ale również analizę i weryfikację programów wykonywanych w systemie.

Obowiązkową kontrolę dostępu stosuje (czy stosowało) się głównie w organiza-

cjach wojskowych, gdzie każdy ma ściśle określoną klauzulę uprzywilejowania, cho-
ciaż coraz częściej w przedsiębiorstwach komercyjnych, w których przetwarzane dane
mają ogromną wartość sięga się po rozwiązania opracowane na potrzeby militarne.

W dalszej części tego rozdziału rozważymy klasyczne modele obowiązkowej kon-

troli dostępu a następnie pokażemy przykłady innych polityk bezpieczeństwa dają-
cych się sprowadzić do modeli obowiązkowej kontroli dostępu.

Zanim przystąpimy do analizy poszczególnych modeli, określimy jeszcze bardziej

precyzyjnie, co należy rozumieć przez przepływ informacji.

Definicja 3.1
Mówimy, że w systemie informacja przepływa z obiektu x do obiektu y, gdy stan
obiektu y zależy w pewien sposób od stanu obiektu x.

W dalszym ciągu w ten właśnie sposób będziemy rozumieć pojęcie przepływu infor-
macji.

3.1

Model Bell–La Padula

Model Bell–La Padula [2] (w skrócie BLP) jest rozbudowanym matematycznym mo-
delem, w którym system komputerowy reprezentowany jest jako maszyna stanowa.
Ze względu na jego złożoność, w poniższej analizie skupimy się tylko na pewnych
jego aspektach, ściśle związanych z zaproponowanym mechanizmem kontroli dostę-
pu. W modelu BLP rozważa się skończony zbiór podmiotów S i obiektów O wraz ze
zbiorem trybów dostępu A = {read, write} określających możliwe sposoby dostępu
podmiotów do obiektów. Kiedy podmiot ma prawo read do obiektu, może go czytać
i kopiować, kiedy ma prawo write, może go modyfikować. Edycja obiektu wymaga
obu tych praw na raz. Gdy podmiot s czyta z obiektu o, informacja przepływa z
obiektu do podmiotu, a gdy podmiot pisze do obiektu, przepływ informacji odbywa
się od podmiotu do obiektu. Ilustruje to rysunek 3.1.

czytanie

pisanie

Rysunek 3.1. Dwa rodzaje przepływu informacji w modelu Bell–LaPadula

W systemie określony jest uporządkowany, skończony zbiór klas bezpieczeństwa

= {C

, C

, . . . , C

> C

> . . . > C

oraz skończony zbiór kategorii K wraz z funkcją f

: S ∪ O → 2

podającą dla każ-

dego obiektu systemu przyporządkowany mu zestaw kategorii, w których ma udział.
O kategoriach można myśleć jako o działach, których dotyczy informacja zawarta
w obiektach. Przykładowo, w przypadku systemu informatycznego przedsiębiorstwa
mogłoby to być

= {księgowość, płace, korespondencja, . . . , personalne},

a dla systemu wojskowego zbiór kategorii mógłby mieć postać

= {personalne, wywiadowcze, nuklearne, . . . , logistyczne}.

Mając powyższe określenia, stan systemu definiujemy następująco

Definicja 3.2

Stanem systemu w modelu BLP nazywamy uporządkowaną parę v = (b, f ), gdzie

b ∈

S×O×A

jest zbiorem trójek postaci (s, o, a) wskazujących, że podmiot s

ma do obiektu o prawo a ∈ A

= (f

, f

), gdzie f

: S ∪ O → C jest funkcją podającą klasyfikację bezpie-

czeństwa natomiast f

: S ∪ O → 2

zwraca zestaw kategorii przyporządko-

wany argumentowi.

Zbiór wszystkich stanów systemu oznaczmy jako V .

W oryginalnej pracy definicja jest bardziej skomplikowana, zawiera bowiem dodat-
kowo pojęcie macierzy dostępu, jednak sprowadza się ona do podanej powyżej, bo-
wiem mając b możemy zawsze uzyskać wartość każdego elementu macierzy dostępu
M

(s, o) = {a ∈ A : (s, o, a) ∈ b}. Podobnie, inne jest określenie funkcji f, jednak

funkcja podana w definicji spełnia tą samą rolę a ma prostszy zapis.

W systemie określony jest też zbiór żądań zmiany stanu systemu, oznaczmy go

przez R. Wówczas funkcją przejścia jest funkcja postaci T : R × V → V . Żądanie r
wystosowane w chwili, gdy system jest w stanie v przenosi system do stanu będą-
cego następnikiem v. Żądania mogą dotyczyć takich działań jak stworzenie nowego
obiektu, przyznanie lub odebranie praw do obiektu czy zmiana funkcji klasyfikacji
bezpieczeństwa obiektów.

Definicja 3.3

System w modelu BLP, oznaczany jako Σ(V, T, v

init

), jest automatem skończonym

o zbiorze stanów V , funkcji przejścia T i stanie początkowym v

init

W modelu tym zdefiniowano dwa podstawowe aksjomaty bezpieczeństwa, aksjo-

mat bezpieczeństwa prostego i tzw. aksjomat gwiazdki. Oba opierają się na założe-
niu, że przepływ informacji jest dozwolony wtedy, gdy zachodzi od obiektu o niższej
klasyfikacji do obiektu o wyższej lub równej klasyfikacji w sensie relacji określonej
jako

s o ⇐⇒ f

(s) ¬ f

(o) ∧ f

(s) ⊆ f

(o).

Definicja 3.4
Stan v = (b, f) systemu Σ spełnia aksjomat bezpieczeństwa prostego, gdy prawdziwy

jest warunek

∀

(s, o, read) ∈ b f

(s)  f

(o) ∧ f

(s) ⊇ f

(o).

Komplementarnym warunkiem odnoszącym się do operacji zapisu jest aksjomat

gwiazdki (ang. ∗-property).

Definicja 3.5
Stan v = (b, f) systemu Σ spełnia aksjomat gwiazdki, jeżeli dla każdego s ∈ S
prawdziwy jest warunek

∀x, y ∈ O

(s, x, read) ∈ b ∧ (s, y, write) ∈ b =⇒ f

(y)  f

(x) ∧ f

(y) ⊇ f

(x).

Znaczenie powyższego warunku jest proste. Jeżeli dany podmiot może czytać z

pewnego obiektu x i ma prawo pisania do innego obiektu y, to klasyfikacja bezpie-
czeństwa x musi być nie większa od klasyfikacji y a zbiór kategorii x musi zawierać
się w zbiorze kategorii y. Jeśli tak jest dla każdego podmiotu s w systemie, stan v
spełnia aksjomat gwiazdki.

Ostatecznie, mając dwie powyższe definicje, możemy zdefiniować bezpieczny stan

systemu.

Definicja 3.6
Stan v = (b, f) systemu Σ jest bezpieczny, jeżeli spełnia on aksjomat bezpieczeństwa
prostego i aksjomat gwiazdki.

Po zdefiniowaniu pojęcia bezpiecznego stanu systemu, kolejnym etapem jest

określenie klasy bezpiecznych systemów, czyli systemów, dla których każdy stan
osiągalny ze stanu początkowego v

init

jest bezpieczny w sensie definicji 3.6. Ponieważ

zmiana stanu systemu zależy od funkcji przejścia T problem sprowadza się do znale-
zienia bezpiecznych, tzn. zachowujących bezpieczny stan systemu, funkcji przejścia.
Warunki te formułuje poniższe twierdzenie, nazywane podstawowym twierdzeniem
bezpieczeństwa (ang. basic security theorem), BST.

Twierdzenie 3.1 (Bell, LaPadula)
System Σ(V, T, v

init

) jest bezpieczny wtedy i tylko wtedy, gdy stan początkowy v

init

jest bezpieczny i funkcja przejścia T spełnia następujące warunki

(1) jeżeli T (v, b) = v

gdzie v

= (b

, f

) wówczas

∀

(s, o, read) ∈ (b

\ b

) f

(s)  f

(o) ∧ f

(s) ⊇ f

(o)

oraz

∀

(s, o, read) ∈ b (f

(s)

(o) ∨ f

(s)

(o)) =⇒ (s, o, read) /

∈ b

(2) jeżeli T (v, b) = v

, gdzie v

= (b

, f

) wówczas

{

(s, x, read), (s, y, write)} ⊆ (b

\ b

) =⇒ f

(y)  f

(x) ∧ f

(y) ⊇ f

(x)

oraz jednocześnie dla każdego {(s, x, read), (s, y, write)} ⊆ b

(y)

(x) ∨ f

(y)

(x)) =⇒ ∀{(s, x, read), (s, y, write)}

Warunki (1) i (2) narzucają ograniczenia na funkcję przejścia w ten sposób, by do-
puścić tylko te funkcje T , które zachowują prawo przepływu informacji od obiektów
o klasyfikacji mniejszej do większej w sensie zdefiniowanej relacji .

W kontekście modelu BLP należy zwrócić szczególną uwagę na fakt, że twierdze-

nie 3.1 nie udowadnia „absolutnego” bezpieczeństwa systemu w sensie potocznego
rozumienia, a jedynie zgodność systemu z pewnymi założeniami co do bezpieczeń-
stwa. Fakt ten, który wskazał McLean, stał się podstawą do krytyki modelu BLP
w jego pracach [43] i [44]. W pracy [44] podany został przykład tzw. systemu Z.
Wyjściowy stan systemu Z jest bezpieczny w sensie definicji 3.6 i posiada on tylko
jeden rodzaj funkcji przejścia opisany poniżej.

Kiedy podmiot s żąda jakiegokolwiek sposobu dostępu do obiektu o,
wszystkie podmioty i obiekty w systemie są degradowane do najniższe-
go możliwego poziomu, a dostęp jest zapisywany w bieżącym zbiorze
dostępu b.

Taka funkcja przejścia zawsze prowadzi do stanu bezpiecznego w sensie definicji z
modelu BLP, a jednak od razu widać, że pozwala ona każdemu na dostęp do wszyst-
kiego, tak więc nie spełnia nawet naszego intuicyjnego rozumienia bezpieczeństwa
w sensie kontroli dostępu. Aby załatać tą lukę, McLean w [46] zaproponował dodat-
kowy mechanizm mający zapobiegać tego typu niepożądanym sytuacjom. Jest on
określony za pomocą uporządkowanej pary C = (c

, c

), gdzie

: S → 2

jest funkcją przyporządkowującą podmiotowi zbiór podmiotów, których poziomy
bezpieczeństwa ma prawo zmienić, a

: O → 2

jest funkcją przyporządkowującą podmiotowi zbiór obiektów, których poziomy bez-
pieczeństwa może on zmienić. Definicja systemu jest identyczna, różnica polega tylko
na innym określeniu funkcji przejścia. Funkcja przejścia jest teraz funkcją

: S × R × V → V

która, gdy podmiot s wystosowuje żądanie r w systemie o stanie v, przemieszcza
system do nowego stanu v

= T (s, r, v).

Definicja 3.7 (McLean)
Funkcję przejścia definiujemy jako funkcję bezpiecznych przejść, jeżeli dla każdego
przejścia v

= T (s, r, v), gdzie v = (b, f) i v

= (b

, f

), spełnione są warunki

(1) ∀x ∈ S f

(x) 6= f

(x) =⇒ s ∈ c

(x)

(2) ∀y ∈ O f

(y) 6= f

(y) =⇒ s ∈ c

(y)

Oznaczają one, że funkcja przejścia może zmienić poziom bezpieczeństwa pod-

miotu x lub obiektu y tylko wtedy, jeżeli podmiot s żądający przejścia znajduje się
w c

(x) lub c

(y) odpowiednio.

Zmodyfikowana definicja bezpieczeństwa mówi, że system jest bezpieczny, jeżeli

(1) wszystkie osiągalne stany spełniają aksjomat bezpieczeństwa prostego i aksjo-

mat gwiazdki (definicje 3.4 i 3.5),

(2) funkcja przejścia jest funkcją bezpiecznego przejścia wg definicji 3.7.

W ten sposób została właściwie określona cała rodzina modeli, różniących się

funkcjami (c

, c

). Zauważmy, że klasyczny model BLP odpowiada sytuacji, gdy

funkcje c

i c

spełniają warunek

(x) = c

(y) = S ∀x ∈ S, y ∈ O,

tak więc model BLP jest najmniej restrykcyjnym spośród modeli zdefiniowanej ro-
dziny. Na drugim końcu znajduje się model, w którym nie ma żadnej możliwości
zmiany poziomu bezpieczeństwa (patrz model SeaView [12]). Pomiędzy nimi znaj-
duje się wiele innych modeli bazujących na BLP, jak chociażby model MMS [35].

Z teoretycznego punktu widzenia, zdefiniowaną rodzinę modeli można rozwa-

żać jako strukturę algebraiczną. W pracy [45] pokazano, jak dla niej skonstruować
operatory ∪, ∩,

, które formują z niej algebrę Boole’a. Dzięki temu otrzymujemy

wygodne narzędzie do badania zależności pomiędzy różnymi modelami rodziny.

3.2

Model kratowy Denning

Intuicyjne znaczenie przepływu informacji i związanych z tym koniecznych ogra-
niczeń na możliwość komunikacji pomiędzy obiektami systemu było zauważane od
początku zainteresowania bezpieczeństwem systemów komputerowych. Jednak mo-
del kratowy Denning opisany w artykule [11] sprecyzował i sformalizował zasady
bezpiecznego przepływu informacji stając się wzorem dla wielu późniejszych prac.

Definicja 3.8 (Denning)

Model przepływu informacji F M jest uporządkowaną piątką

F M

= (O, S, SC, ⊕, →)

gdzie

1. O jest zbiorem obiektów systemu,

2. S jest zbiorem procesów systemu (S ⊆ O),

3. SC jest zbiorem klas (poziomów) bezpieczeństwa,

4. ⊕: SC × SC → SC jest operatorem łączenia klas,

5. → ⊆ SC × SC jest relacją przepływu informacji.

Trzy pierwsze elementy modelu nie wymagają wyjaśnień, są one identyczne jak w
przypadku innych modeli.

Każdemu obiektowi i podmiotowi systemu odpowiada jego klasa bezpieczeństwa.

Mamy więc do czynienia z funkcją c : O → SC. Dla uproszczenia zapisów za
oryginalnym artykułem będziemy stosować oznaczenie c(o) = o, a więc s oznacza
klasę bezpieczeństwa przyporządkowaną procesowi s.

Nowością jest operator ⊕. Jest to łączny i przemienny operator, który dla każ-

dych dwóch klas będących jego argumentami podaje klasę wyniku dowolnej dwuar-
gumentowej operacji na obiektach, których klasy były argumentami operacji ⊕. Tak
więc jeśli wykonamy jakieś operacje (oznaczmy je jako funkcję f) na dwóch obiek-
tach a, b ∈ O to ich wynik w = f(a, b) będzie miał klasę bezpieczeństwa w = a ⊕ b.
Zauważmy, że zakłada to, że klasa bezpieczeństwa wyniku dowolnej operacji zale-
ży tylko od klas bezpieczeństwa argumentów a nie od rodzaju operacji. Okazuje
się jednak, że założenie to nie zmniejsza ogólności rozważań, gdyż efekt zależności
operatora ⊕ od rodzaju funkcji może być symulowany poprzez odpowiedni dobór

procesów korzystających z niezależnego od funkcji operatora ⊕ [10]. Oczywiście
zbiór SC jest zamknięty ze względu na operator łączenia klas.

Relacja przepływu → jest określona dla par klas bezpieczeństwa. Dla klas A i B

piszemy A → B wtedy i tylko wtedy, gdy informacja z klasy A ma prawo przepływać
do klasy B.

Sformułowanie warunku bezpieczeństwa z wykorzystaniem powyższych definicji

jest już proste.

Definicja 3.9 (Denning)
Model przepływu F M jest bezpieczny wtedy i tylko wtedy, gdy nie istnieje ciąg
operacji, który powoduje przepływ informacji sprzeczny z relacją →.

Ważnym rezultatem było pokazanie, że struktura (SC, →, ⊕, ⊗), gdzie ⊗ jest

operatorem kresu dolnego na parach elementów zbioru SC, tworzy kratę zupełną.
Rzeczywiście tak jest, gdyż [10]

jest zbiorem skończonym

(SC, →) jest zbiorem częściowo uporządkowanym, co wynika z własności re-
lacji →,

ma ograniczenie dolne L takie, że ∀A ∈ SC L → A,

⊕

jest operatorem kresu górnego w SC.

Z powyższych własności wynika istnienie operatora kresu dolnego ⊗, który jest
określony jako (patrz [10])

A ⊗ B

: C → A ∧ C → B}

gdzie symbol

oznacza operator kresu górnego dla zbioru elementów oraz istnienie

ograniczenia górnego H dla całego zbioru SC spełniającego warunek

∀A ∈ SC

A → H.

Daje to nowe spojrzenie na problem bezpiecznego przepływu informacji i pozwala
na formalne jego ujęcie w ramach dobrze znanych narzędzi matematycznych. Dzięki
temu proces projektowania mechanizmu kontroli dostępu opartego na kontroli prze-
pływu informacji staje się bardziej przejrzysty.

Zauważmy, że opisany wcześniej model BLP przepływu informacji de facto two-

rzy kratę zupełną. Mamy w nim SC = C × K, funkcja c przyporządkowująca obiek-
towi jego klasę bezpieczeństwa to funkcja c(o) = (f

(o), f

(o)), relacja przepływu

jest zdefiniowaną poprzez relację , tzn.

→ o

⇐⇒ f

) ¬ f

) ∧ f

) ⊆ f

czyli o

→ o

⇐⇒ o

 o

Operator kresu górnego jest określony jako

⊕ o

= (max{f

), f

)}, f

) ∪ f

)) ,

zaś operator kresu dolnego ma postać

⊗ o

= (min{f

), f

)}, f

) ∩ f

)) .

Elementem maksymalnym dla całego zbioru SC jest (max SC, K) zaś minimalnym
(min SC, ∅).

W ten sposób wykazaliśmy, że warunki bezpiecznego dostępu do informacji w

modelu BLP w istocie określają strukturę kratową tak, jak opisała to w swojej
pracy Denning.

Dla przykładu rozważmy zbiór kategorii K = {osobowe, gospodarcze} i zbiór

klas bezpieczeństwa {jawne, poufne, tajne}. Wówczas krata opisująca bezpieczne
przepływy informacji będzie mieć postać przedstawioną na rysunku 3.2.

(j,{})

(p,{})

(j,{o})

(j,{g})

(t,{})

(p,{o})

(j,{o,g})

(p,{g})

(t,{o})

(p,{o,g})

(t,{g})

(t,{o,g})

Rysunek 3.2. Krata bezpiecznych przepływów informacji

3.3

Model kratowy dla polityki chińskiego muru

Podejście oparte na modelowaniu przepływu informacji za pomocą krat znalazło
zastosowanie również do opisu polityki „chińskiego muru”. Polityka ta, zidentyfi-
kowana i opisana przez Brewera i Nasha [8] jest pewnym rodzajem obowiązkowej
kontroli dostępu. Jej motywacją jest obserwacja firm doradzających finansowo przed-
siębiorstwom. Firmy takie z pewnością gromadzą dane o swoich klientach. Często
ich klientami są przedsiębiorstwa tej samej branży, będące potencjalnymi konkuren-
tami. Dlatego też ważne jest, by pracownik zajmujący się analizą stanu pewnego
przedsiębiorstwa nie miał dostępu do informacji o firmach mogących być konkuren-
cją dla tych, którym doradza, gdyż wówczas mógłby (świadomie lub nie) działać na
szkodę któregoś z nich.

Dlatego też firmy, których informacje nie powinny być dostępne jednocześnie, są

pogrupowane w klasy „konfliktu interesów” (ang. conflict of interest), COI. Każda
firma należy do dokładnie jednej klasy COI. Konsultant nie ma prawa mieć dostępu
do informacji więcej niż jednego przedsiębiorstwa należącego do tej samej klasy
konfliktu interesów.

Brewer i Nash zaproponowali następujące reguły określające możliwość dostępu

do danych:

1. Reguła czytania: podmiot s może czytać z obiektu o, gdy

obiekt o zawiera informacje o przedsiębiorstwie, którego dane podmiot s
już wcześniej czytał

należy do takiej klasy COI, z której podmiot s jeszcze nie czytał danych

o żadnym przedsiębiorstwie

2. Reguła pisania: podmiot s może pisać do obiektu o, gdy

podmiot s ma prawo odczytu do obiektu o zgodnie z poprzednią regułą
i żaden inny obiekt, który zawiera dane o innej firmie niż o nie może być
odczytany zgodnie z regułą czytania

Drugi z warunków oznacza, że podmiot, który może czytać informację z dokładnie
jednej firmy, może też tam zapisywać informację. Podmiot, który może czytać z wię-
cej niż jednej klasy COI, nie ma prawa zapisu nigdzie. Jest to mechanizm ochronny
przed możliwością niejawnego przepływu informacji pomiędzy konsultantami zaj-

mującymi się firmami w konflikcie interesów poprzez dane trzeciej firmy nie będącej
w konflikcie z żadną z dwóch.

Za Sandhu [54] pokażemy, że opisaną powyżej politykę „chińskiego muru” można

wyrazić w postaci modelu kratowego przepływu informacji. Przedstawimy tu nieco
zmodyfikowaną wersję konstrukcji podanej w [54].
A1. Istnieje n klas konfliktów interesów COI

, . . . , COI

A2. Każda klasa COI

składa się z numerów przedsiębiorstw 1, 2, . . . , m

dla i =

1, . . . , n, które pozostają w konflikcie interesów.

Każdy obiekt systemu posiada swoją etykietę, w której oznaczony jest fakt, z któ-

rych przedsiębiorstw zawiera on informację. Ponieważ zgodnie z określoną polityką
bezpieczeństwa nie może on zawierać informacji z więcej niż jednego przedsiębior-
stwa z danej klasy COI, etykieta jest ciągiem n elementów zawierających informację
o tym, czy obiekt zawiera dane z klas COI i którego przedsiębiorstwa są to dane. Je-
żeli obiekt zawiera dane z k-tego przedsiębiorstwa klasy COI

, wówczas w etykiecie

na j-tym miejscu występuje liczba k. Jeżeli obiekt nie ma żadnych informacji przed-
siębiorstw z klasy COI

, na j-tym miejscu występuje specjalny symbol ⊥. Formalnie

jest to wyrażone poprzez następującą konstrukcję
A3. LABELS = COI

× COI

× . . . × COI

, gdzie COI

= COI

∪ {⊥}

Ponieważ przy takiej konstrukcji nie istnieje naturalnie wyznaczony element naj-

większy, definiujemy go rozszerzając zbiór etykiet następująco
A4. EXT LABELS = LABELS ∪ {SY SHIGH} gdzie SY SHIGH oznacza wpro-
wadzony element największy. Etykieta ta nie jest przydzielana żadnemu obiektowi
systemu.

Kolejnym krokiem jest wprowadzenie relacji porządkującej zbiór EXT LABELS.

Dla etykiet obiektów systemu jest ona określona następująco
A5. ∀l

, l

∈ LABELS

 l

⇐⇒

(∀k = 1 . . . n l

[k] = l

[k] ∨ l

[k] =⊥).

Do relacji włączamy również element SY SHIGH poprzez warunek

A6. ∀l ∈ EXT LABELS

SY SHIGH l

Do zdefiniowania kraty pozostało jeszcze określić operator kresu górnego sup dla

par etykiet. W tym celu wprowadzamy najpierw pojęcie etykiet kompatybilnych.
A7. l

, l

∈ LABELS

są kompatybilne

⇐⇒

(∀k = 1 . . . n (l

[k] = l

[k]) ∨ (l

[k] =⊥) ∨ (l

[k] =⊥))

Dla pary niekompatybilnych etykiet ich kresem górnym jest SY SHIGH, co

przedstawia warunek
A8. Jeżeli l

i l

są niekompatybilne, to sup(l

, l

) = SY SHIGH

W przypadku kompatybilnych etykiet warunek jest następujący

A9. Jeżeli l

i l

są kompatybilne, to sup(l

, l

) = l

, gdzie

[k] =







[k]

gdy l

[k] 6=⊥,

[k]

w przeciwnym razie.

Ostatnim koniecznym uzupełnieniem jest określenie, w jaki sposób ma zachowywać
się operator sup, gdy jedną z etykiet składowych jest SY SHIGH. Definiuje to
warunek
A10. ∀l ∈ EXT LABELS

sup(l, SY SHIGH) = SY SHIGH.

Każdemu podmiotowi systemu przypisywana jest na początku jego istnienia ety-

kieta odpowiadająca etykiecie użytkownika systemu, na rzecz którego działa ten
podmiot.

Definicja modelu kratowego dla polityki chińskiego muru jest już kompletna.

Dzięki niej możemy teraz w inny sposób wyrazić warunki na możliwość czytania
i pisania do obiektów zgodnie z polityką chińskiego muru.

Kratę bezpiecznych przepływów informacji dla prostego przypadku, w którym

istnieją tylko dwie klasy konfliktu interesów a w każdej klasie są tylko dwa przedsię-
biorstwa przedstawia rysunek 3.3. Oznakowanie [1, ⊥] mówi, że oznakowane tak dane
zawierają tylko informację z pierwszego przedsiębiorstwa z pierwszej klasy konfliktu
interesów, natomiast [2, 1] oznacza, że dane zawierają informację z drugiego przed-
siębiorstwa należącego do pierwszej klasy konfliktu interesów oraz dane z pierwszego
przedsiębiorstwa należącego do drugiej klasy konfliktu interesów.

[ , ]

[1, ]

[ ,1]

[ ,2]

[2, ]

[1,1]

[1,2]

[2,1]

[2,2]

SYSHIGH

Rysunek 3.3. Krata bezpiecznych przepływów informacji dla polityki chińskiego mu-
ru.

Podmiot s może mieć dostęp do czytania obiektu o wtedy i tylko wtedy, gdy

(s)  L(o),

natomiast ma prawo dostępu do pisania do obiektu o gdy

(s) ¬ L(o),

gdzie L(s) oznacza etykietę podmiotu s, zaś L(o) oznacza etykietę obiektu o.

Widać wyraźnie, że powyższe warunki są znanymi aksjomatami bezpieczeństwa

prostego i gwiazdki z modelu BLP. W ten sposób zastosowanie modelowania z uży-
ciem krat i przepływu informacji sprowadziło wydawałoby się zupełnie odmienną
politykę bezpieczeństwa do ram dobrze przebadanej polityki obowiązkowej kontroli
dostępu.

3.4

Podsumowanie własności obowiązkowej kon-

troli dostępu

Z przeprowadzonej powyżej analizy widać, że w systemach, w których należy lub
trzeba z góry określić poziomy wrażliwości czy tajności dla użytkowników lub pew-
nych danych systemu, konieczne jest stosowanie mechanizmów obowiązkowej kon-
troli dostępu. W przeciwieństwie do kontroli uznaniowej pozwalają one nie tylko na
śledzenie, ale na dokładne wytyczanie kanałów, którymi może rozprzestrzeniać się
informacja w systemie.

Warto zaznaczyć, że modelowanie przepływu informacji, jeden z głównych fun-

damentów modeli rozważanych w tym rozdziale, stosowane jest również w szerszym
kontekście. Wraz z dynamicznym wzrostem popularności języka Java [20], [61] i wy-
korzystaniem go do programowania aplikacji internetowych (aplety, itp.) nabrały
praktycznego znaczenia metody analizy przepływu informacji w programach, jak
np. [23], zapoczątkowane m.in. przez omawianą pracę Denning w [11].

Wydaje się, że modelowanie oparte na przepływie informacji uzyskało już zasłu-

żoną pozycję wśród modeli bezpieczeństwa zarówno systemów operacyjnych jak i baz
danych czy przenośnego kodu. Dalsze badania z pewnością powinny koncentrować
się na dostosowaniu tego rodzaju modeli do potrzeb zróżnicowanych środowisk roz-
proszonych. Ważnym problemem wydaje się również analiza wpływu współbieżności
na bezpieczeństwo przepływu informacji.

Rozdział 4

Kontrola dostępu oparta na rolach

Fundamentalną obserwacją, jaka legła u podstaw tego modelu kontroli dostępu jest
fakt, iż w większości organizacji prawa, jakie przysługują pracownikowi zależą od
stanowiska, czyli roli, jaką pełni w organizacji, a nie od tego, jaka jest jego tożsa-
mość. Jan Kowalski awansując w organizacji otrzymuje nowe uprawnienia, mimo że
nadal jest Janem Kowalskim. Zatem prawa dostępu do zasobów systemu informa-
tycznego powinny zależeć raczej od jego pozycji w organizacji a nie od tego, czy
użytkownik jest Janem Kowalskim czy Zdzisławem Nowakiem. Takie rozgraniczenie
pozwala na elastyczniejsze administrowanie prawami w systemie, gdyż rozdziela etap
przydzielania praw potrzebnych do wykonywania określonych zadań od określania,
kto zadania te ma wykonywać.

4.1

Model Sandhu–Coyne kontroli opartej na ro-

lach

Modele kontroli dostępu opartej na rolach powstały w latach 90-tych. Jedną z wcze-
śniejszych prac była [15], opiszemy tu jednak za [57] model przedstawiony przez
Sandhu, Coyne i współpracowników. Stał się on już wzorcowym rozwiązaniem zna-
nym pod nazwą RBAC96.

W rzeczywistości RBAC96 definiuje rodzinę modeli różniącą się dodatkowymi

możliwościami. RBAC

jest podstawowym modelem wprowadzającym elementarne

mechanizmy kontroli bazującej na rolach. Kolejnymi modelami są RBAC

i RBAC

które rozszerzają podstawowy model o hierarchie ról i ograniczenia ról odpowiednio.
Najbardziej kompletnym modelem jest RBAC

, który łączy w sobie cechy wszystkich

powyższych modeli.

Definicja 4.1 (Sandhu et al.)

Model RBAC

jest strukturą (U, R, P, S, P A, UA, user, roles), gdzie

, R, P , S są zbiorami użytkowników, ról, praw dostępu i sesji odpowiednio,

P A ⊆ P × R

jest relacją przyporządkowującą rolom uprawnienia (prawa),

U A ⊆ U × R

jest relacją przyporządkowującą użytkownikom role jakie pełnią,

user

: S → U jest funkcją, która każdej sesji s przyporządkowuje użytkownika

= user(s) na rzecz którego działa sesja,

roles

: S → 2

jest funkcją przyporządkowującą sesji podzbiór ról, jakimi dys-

ponuje użytkownik danej sesji.

Zgodnie z powyższą definicją, U jest zbiorem użytkowników danego systemu. R ozna-
cza zbiór ról, jakie są dostępne w systemie i jakie mogą pełnić użytkownicy.

Zbiór określonych w systemie uprawnień (praw dostępu i innych) oznaczamy jako

. Mogą one dotyczyć sposobu dostępu do obiektów systemu, jak również określać

innego rodzaju przywileje. Choć samo pojęcie obiektów w modelu nie występuje, to
jednak jest ono niejako „wbudowane” w prawa. Nie rozróżnia się po prostu obiek-
tów i praw do nich, ale każde prawo może określać odpowiedni rodzaj dostępu do
określonego obiektu.

Wyjaśnienia wymaga koncepcja sesji. Sesję należy rozumieć jako wykonywanie

pewnego zadania w systemie poprzez określonego użytkownika. Każdy użytkownik
może jednocześnie wykonywać wiele zadań (np. ma otwarte wiele okien terminali)
i każda sesja może być wykonywana z innymi uprawnieniami. W szczególnym przy-
padku jako sesje można rozumieć procesy, których właścicielem jest użytkownik.

Kluczowym elementem modelu są dwie relacje P A i UA. Pierwsza z nich, P A ⊆

P × R

określa przyporządkowanie uprawnień rolom. W zależności od rodzaju roli,

przydzielamy jej odpowiednie uprawnienia. Dzięki temu każda rola r ∈ R ma zbiór
przyporządkowanych jej uprawnień postaci

{p ∈ P

: (p, r) ∈ P A}.

Analogicznie zdefiniowana jest relacja UA ⊆ U × R, która określa, jakimi rolami

dysponują użytkownicy. Użytkownik u ∈ U ma do dyspozycji zbiór ról określony
jako

{r ∈ R

: (u, r) ∈ UA}.

Za pomocą funkcji roles określa się dla danej sesji zbiór ról dostępnych sesji, któ-

ry jest podzbiorem zbioru ról przydzielonych użytkownikowi będącemu właścicielem
sesji, tzn.

roles

(s) ⊆ {r ∈ R : (user(s), r) ∈ UA}.

Celem wprowadzenia tej funkcji jest zapewnienie użytkownikowi możliwości urucha-
miania sesji o prawach „okrojonych” w stosunku do jego uprawnień wynikających z
przyporządkowania UA. Dzięki temu użytkownik może mieć np. możliwość urucha-
miania z ograniczonymi prawami kodu, któremu nie ufa.

Schemat zależności pomiędzy elementami składowymi modelu RBAC

przedsta-

wia rysunek 4.1.

u¿ytkownicy

role

prawa

relacja

S - sesje

...

funkcja user

funkcja roles

Rysunek 4.1. Elementy składowe i powiązania w modelu RBAC

Ostatecznie, efektywne uprawnienia, jakimi dysponuje sesja s danego użytkow-

nika są określone jako

[

∈roles(s)

{p ∈ P

: (p, r) ∈ P A}.

Rozszerzeniem możliwości podstawowego modelu RBAC

jest wprowadzenie do

niego hierarchii ról. Pomysł hierarchii, w której możliwości działania są dziedziczone
od „starszych” pokoleń jest dobrze znany z programowania obiektowego. Przykła-
dową hierarchię ról obrazuje rysunek 4.2.

W przypadku modelu RBAC hierarchia ról zdefiniowana jest za pomocą relacji

częściowego porządku w zbiorze R. Definicja modelu RBAC

jest więc następująca.

Definicja 4.2 (Sandhu)
Model RBAC

jest strukturą (U, R, RH, P, S, P A, UA, user, roles), gdzie

U, R, P, S, P A, U A, user

mają takie same znaczenie jak w modelu RBAC

pracownik

programista

kierownik

analityk

ksiêgowa

Rysunek 4.2. Przykładowa hierarchia ról w przedsiębiorstwie.

RH ⊆ R×R

, oznaczana też przez , jest relacją częściowo porządkującą zbiór

funkcja roles : S → 2

jest tak zmodyfikowana, by spełniać warunek

∀s ∈ S

roles

(s) ⊆ {r : ∃r

 r

(user(s), r

) ∈ UA}.

Drugi warunek oznacza, że role przyporządkowane sesji są podzbiorem zbioru tych
ról, dla których istnieją „większe” (starsze) role w zbiorze ról będących w relacji UA
z użytkownikiem sesji.

Przy takiej definicji wzór opisujący efektywne prawa sesji ma postać

[

∈roles(s)

{p ∈ P

: ∃r

¬ r

(p, r

) ∈ P A}.

Oznacza on, że sesja ma wszystkie prawa, które wynikają z ról przypisanych jej przez
funkcję user(s) oraz wszystkich ról mniejszych od nich w sensie relacji porządkującej
zbiór R.

Innym rozszerzeniem modelu RBAC

jest RBAC

, w którym wprowadzono me-

chanizm ograniczeń (ang. constraints) (patrz także [18]). Są to reguły, zgodnie z
którymi pewne stany systemu kontroli dostępu nie mogą wystąpić. Mogą one ogra-
niczać ilość użytkowników przydzielonych do danej roli, ilość ról, jakie jednocześnie
pełni użytkownik, czy nakładać ograniczenia na to, których ról nie można pełnić jed-
nocześnie. Przykładowo, w systemie mogą istnieć wzajemnie wykluczające się role,
tzn. takie, że ten sam użytkownik nie może pełnić jednocześnie ich obu. Przykła-
dem mogą być role „poręczyciel” i „kredytobiorca”. Formalny model uwzględniający
takie ograniczenia przedstawiony został w [17].

Ostatecznie, pełny model RBAC

jest połączeniem cech modeli RBAC

i RBAC

tzn. modelem zawierającym zarówno hierarchie ról jak i ograniczenia. Obrazuje to
rysunek 4.3. Często dla uproszczenia pełny model RBAC

jest nazywany po prostu

RBAC.

RBAC

hierarchie

ról

ograniczenia

Rysunek 4.3. Zależności pomiędzy różnymi modelami rodziny RBAC.

4.2

Role administracyjne

Oczywiście w systemie potrzebna jest możliwość zmiany przyporządkowań P A i UA,
a więc wpływania na kształt kontroli dostępu. Powyższy opis zakładał niejawnie, że
możliwość zmiany wszystkich parametrów ma jedna absolutnie zaufana jednostka.
Jednak w dużych organizacjach ich system informatyczny może posiadać dziesiątki
tysięcy użytkowników, mieć zdefiniowane setki lub tysiące ról a ilość możliwych do
przydzielenia praw może być liczona w milionach. Dlatego też kluczową dla skalowal-
ności modelu cechą jest możliwość rozdzielenia zadań administracji rolami pomiędzy
większą ilość osób. W tym celu wprowadza się pojęcie ról administracyjnych, których
uczestnicy mają prawo do zmian relacji P A i UA oraz zbiorów U, R, P . Modele ta-
kie z uwzględnieniem ról administracyjnych były badane w ostatnich latach a różne
wersje modeli przedstawiają m.in. prace [56], [55], [58]. Wprowadzony został w nich
zbiór AR ról administracyjnych, zbiór AP praw administracyjnych oraz analogiczne
do UA i P A relacje AUA ⊆ U × AR oraz AP A ⊆ AP × AR określające sposób
przydzielania użytkownikom ról administracyjnych oraz praw administracyjnych ro-
lom administracyjnym. W zbiorze ról administracyjnych również określa się relację
częściowo porządkującą tak, aby uzyskać hierarchię tych ról pozwalającą rolom nad-
rzędnym w sensie tego uporządkowania na wykonywanie czynności określonych dla
ról podrzędnych. Już to pozwala na elastyczne konfigurowanie mechanizmu kontroli

dostępu, można jednak wprowadzać dalsze usprawnienia.

Przykładowo, w pracy [55] opisany został model opartego na rolach administro-

wania przydzielaniem ról użytkownikom, a więc modyfikowania relacji UA. Wpro-
wadza się w nim pojęcie warunków wstępnych koniecznych do przydzielenia roli.

Definicja 4.3 (Sandhu)

Warunkiem wstępnym jest wyrażenie logiczne używające operatorów logicznych ∨,

∧

łączących wyrażenia x i x. Wartość logiczna warunku wstępnego jest obliczana

dla użytkownika u poprzez podstawienie za x true wtedy i tylko wtedy, gdy

∃x

 x

(u, x

) ∈ UA

i podstawienie false w przeciwnym razie oraz podstawienie za x true wtedy i tylko
wtedy, gdy

∀x

 x

(u, x

) /

∈ UA

i podstawienie false w przeciwnym razie. Zbiór wszystkich warunków wstępnych
możliwych do określenia dla zbioru ról R oznaczymy przez CR.

Po wprowadzeniu definicji warunku wstępnego, autorzy określają relację can-

-assign jako

can-assign ⊆ AR × CR × 2

Wówczas znaczenie can-assign(x, y, W ) jest takie, że członek roli administracyjnej
x

(albo roli nadrzędnej w stosunku do x) ma prawo przydzielić role ze zbioru W

użytkownikowi, który spełnia warunek wstępny y ∈ CR.

Podobnie, relacja can-revoke została określona jako

can-revoke ⊆ AR × 2

Zapis can-revoke(x, Y ) oznacza, że członek roli administracyjnej x ∈ AR ma prawo
anulować uczestnictwo użytkowników w rolach ze zbioru Y ⊆ R.

W podobny sposób można określić role administracyjne zarządzające przydzie-

laniem praw do ról, przykładowe rozwiązanie podano w pracy [58].

Dzięki takim modyfikacjom zadanie administrowania rolami oraz przydzielanie

użytkowników i praw do odpowiednich ról może zostać rozdzielone pomiędzy większą
ilość osób, pozwala więc na rozproszone administrowanie systemem kontroli dostępu
bez konieczności każdorazowej interwencji nadrzędnego autorytetu, co w przypadku
bardzo dużych struktur ma kluczowe znaczenie.

4.3

RBAC a inne modele kontroli dostępu

Można postawić pytanie, jak ma się RBAC do innych, omówionych wcześniej mode-
li. Okazuje się, że model ten jest najbardziej ogólnym z modeli, gdyż za jego pomocą
można symulować zarówno uznaniową jak i obowiązkową kontrolę dostępu. Przed-
stawimy tu za [50] sposoby skonstruowania mechanizmów kontroli dostępu bazują-
cych na rolach, które symulują działanie mechanizmów uznaniowej i obowiązkowej
kontroli dostępu.

Poddajmy najpierw analizie model uznaniowej kontroli dostępu (DAC). Zauważ-

my, że w modelu DAC zmiana praw dostępu do obiektu zależy od jego właściciela.
Ponadto, twórca obiektu staje się jego właścicielem, istnieje tylko jeden właściciel
danego obiektu, a obiekt może być zniszczony tylko przez jego właściciela. W zależ-
ności od sposobu rozwiązania kwestii przekazywania praw (polecenie grant) różne
są odmiany modelu DAC. Jako przykład rozważymy tutaj odmianę modelu, w któ-
rym tylko właściciel ma prawo udzielać dostępu do obiektów a własność obiektu nie
może być zmieniana. W pracy [50] opisany jest również sposób symulacji modelu, w
którym można przekazywać prawo do udzielania dostępu do obiektów oraz sytuacja,
w której możliwe jest przekazywanie własności obiektu.

W czasie tworzenia, dla każdego nowego obiektu o

w zbiorze ról administracyjnych AR tworzona jest jednocześnie odpowiadająca
mu rola OW N

, a w zbiorze zwykłych ról rola READ

do zbioru praw dodawane jest prawo canRead

, które przyporządkowane jest

roli READ

do zbioru praw dodawane jest prawo canDestroy

, które przyporządkowywane

jest roli OW N

do zbioru praw praw administracyjnych dodawane są prawa addReadUser

i deleteReadUser

, które pozwalają na przydzielanie użytkowników do roli

READ

i usuwanie ich z niej. Prawa te przydzielane są roli OW N

użytkownikowi, który stworzył obiekt o przydzielana jest rola OW N

, a co za

tym idzie również rola READ

Na skutek takiej konstrukcji twórca–właściciel ma prawo własności do obiektu, dzię-
ki któremu poprzez przydzielanie roli READ

może innym przyznawać prawo do

czytania z obiektu (symulacja polecenia grant). W analogiczny sposób poprzez do-
dawanie odpowiednich ról i praw można wzbogacać możliwości modelu o obsługę
praw pisania, dopisywania, itd.

Usunięcie obiektu o wymaga jednoczesnego usunięcia stworzonych uprzednio ról

OW N

, READ

, praw canRead

, canDestroy

, addReadUser

, deleteReadUser

oraz usunięcie odpowiednich przyporządkowań z relacji UA, P A, AUA, AP A.

Można pokazać, że taki model odpowiada uznaniowej kontroli dostępu. Precy-

zyjną z formalnego punktu widzenia konstrukcję potrzebną do uzasadnienia tego
faktu można znaleźć w [47]. W pracy tej znajdują się jeszcze dalej idące rezultaty,
pokazujące że model RBAC może symulować także modele TAM i ATAM będące
uogólnieniami modelu uznaniowej kontroli dostępu.

Pokażemy teraz, w jaki sposób za pomocą modelu RBAC można symulować mo-

del obowiązkowej kontroli dostępu (MAC) opartej o kontrolę przepływu informacji.
W tym celu odwzorujemy kratę klas bezpieczeństwa na odpowiednią hierarchię ról.
Zauważmy, że podmioty (użytkownicy) będący „wyżej” w kracie klas bezpieczeń-
stwa posiadają więcej możliwości czytania danych, ale mniej możliwości ich zapisu.
Dlatego też tworzona w symulacji hierarchia ról musi mieć charakter dualny, jedna
hierarchia dla odczytu i druga dla zapisu.

Ponieważ w modelu MAC każdy użytkownik posiada swoją klasę bezpieczeń-

stwa, w RBAC musi mieć przyporządkowane dokładnie dwie role, xR i LW , jedną
dla określenia możliwości czytania, a drugą dla zdefiniowania możliwości zapisu. W
modelu MAC ma on możliwość zalogowania się na każdym poziomie bezpieczeństwa
zdominowanym przez jego poziom (a więc na wszystkich poziomach „niższych”). W
modelu RBAC jest to odwzorowane za pomocą warunku, że każda sesja posiada
dokładnie dwie role yR i yW . Warunek, by x y jest spełniony niejako z założenia,
gdyż wymusza go definicja RBAC (sesjom można przyporządkować podzbiory ról
dostępnych dla użytkownika).

Podamy teraz formalną konstrukcję pochodzącą z [50]. Załóżmy, że mamy dany

model MAC ze zbiorem klas bezpieczeństwa SC = {L

, L

, . . . , L

}

, w którym okre-

ślona jest relacja porządkująca

M AC

. Wówczas odpowiadający jej model RBAC ma

następującą postać.

1. R = {L

R, L

R, . . . , L

R, L

W, L

W, . . . , L

W }

2. relacja porządkująca role RH składa się z dwóch rozłącznych hierarchii. Jed-

na składa się z ról „czytania” {L

R, . . . , L

, w której porządek jest okre-

ślony tak samo jak definiuje to relacja

M AC

, druga składa się z ról „pisa-

nia” {L

W, . . . , L

W }

, a jej porządek jest odwrotny do tego określonego przez

M AC

3. P = {(o, r), (o, w) : o jest obiektem systemu}

4. ograniczenia na UA: każdy użytkownik jest przypisany do dokładnie dwóch ról

i LW , gdzie x jest poziomem bezpieczeństwa związanym z użytkownikiem

a LW oznacza rolę odpowiadającą najniższemu poziomowi bezpieczeństwa
względem wyjściowej relacji

M AC

5. ograniczenia na sesje: każda sesja ma przyporządkowane dokładnie dwie role

i yW ,

6. ograniczenia na P A:

(o, r) jest przyporządkowane do xR wtedy i tylko wtedy, gdy (o, w) jest
przyporządkowane do xW

(o, r) jest przyporządkowane do dokładnie jednej roli xR takiej, że x jest
klasą bezpieczeństwa o.

Mając taką konstrukcję, można wykazać następujące twierdzenie mówiące o tym, że
tak sformułowany model spełnia warunki bezpiecznego przepływu informacji.

Twierdzenie 4.1 (Osborn)
System RBAC zdefiniowany za pomocą powyższej konstrukcji spełnia aksjomat bez-
pieczeństwa prostego (definicja 3.4) i aksjomat gwiazdki (definicja 3.5).

Wyniki te pokazują, że model kontroli dostępu opartej na rolach jest bardzo ela-

styczny i pozwala na symulowanie działania innych popularnych modeli. Jest to więc
najbardziej ogólny model spośród wymienionych do tej pory. Należy jednak zwrócić
uwagę na fakt, że w praktyce symulacja innego modelu kontroli dostępu za pomocą
RBAC może być zagrożona słabą wydajnością. Dlatego też w przypadku konieczno-
ści takiej symulacji, w systemie należy bardzo starannie przeanalizować wszystkie
czynniki mogące mieć wpływ na obniżenie wydajności działania mechanizmu, by w
miarę możliwości zapobiec temu zjawisku.

4.4

Podsumowanie cech RBAC

Mechanizmy kontroli dostępu oparte na rolach stanowią stosunkowo nowy i bardzo
dynamicznie rozwijający się kierunek badań. Zainteresowanie RBAC jest uzasad-
nione przez wiele jego zalet. Zaliczyć do nich można neutralność w stosunku do
polityki bezpieczeństwa, co znaczy, że za jego pomocą można modelować różne poli-
tyki. Model ten powstał z myślą o uproszczeniu zadań administracyjnych w dużych
systemach i jako taki może znacznie uprościć zarządzanie rozległymi systemami
informatycznymi. Posiada on możliwości pozwalające na rozproszone administrowa-
nie, które czynią go modelem najbardziej skalowalnym. Dlatego też model RBAC
wzbudził znaczne zainteresowanie fachowców i stał się nawet przedmiotem prac w
NIST [48] co oznacza, że być może zostanie opracowany jednolity standard dotyczą-
cy tego modelu.

Jeżeli chodzi o kwestie bezpieczeństwa, to ze względu na ogólność modelu, nie

daje się określić wiele własności prawdziwych dla każdego modelu RBAC. To, że
można go skonfigurować tak, by zachowywał się jak model z uznaniową kontro-
lą dostępu pokazuje, że w pewnych wypadkach nie da się rozstrzygać o problemie
bezpieczeństwa informacji w tym systemie. Wydaje się jednak, że dla wielu sensow-
nych (przydatnych praktycznie) mechanizmów opartych na RBAC ograniczenia na
prawa ról i przyporządkowania ról użytkownikom pozwalają na tworzenie mecha-
nizmów, w których rozprzestrzenianie się informacji może być ściśle kontrolowane.
Jest to jednak problem mało przebadany w literaturze. Prosty przypadek wykaza-
nia równoważności przepływów informacji za pomocą izomorfizmu grafów pokazała
Nyanchama i Osborn w pracy [49]. Interesujące podejście zaproponował Koch at al
w artykule [32], przedstawiając grafową reprezentację modelu, dzięki której możliwe
było badanie pewnych jego własności za pomocą systemów transformacji grafów [52].
Wydaje się to być obiecującym kierunkiem badań, który być może pozwoli na roz-
strzyganie o problemach bezpieczeństwa modelu RBAC.

Dodatkową interesującą cechą charakterystyczną RBAC wydaje się być jego po-

datność na modyfikacje dopasowane do konkretnych potrzeb. Model kontroli dostępu
opartej na rolach często okazuje się dobrym punktem wyjścia do wzbogacania go
o nowe elementy, wprowadzające nowe cechy lub usprawniające istniejące do tej
pory. Kilka przykładów takich modyfikacji przedstawionych zostanie w następnym
rozdziale.

Rozdział 5

Proponowany model kontroli

dostępu wraz z przykładową

implementacją

W rozdziale tym przedstawimy opis zmodyfikowanego modelu kontroli dostępu opar-
tego o role, w którym sprecyzowane zostanie pojęcie obiektów systemu oraz wpro-
wadzony będzie nowy element w postaci domen grupujących obiekty. Następnie
zaprezentujemy projekt systemu dostarczającego usługę zdalnego przechowywania
i współdzielenia plików, w którym zastosowany został sformułowany model kontroli
dostępu. Omówione zostaną również niektóre zagadnienia projektowe i implemen-
tacyjne związane z systemem.

5.1

Opis modelu

Motywacją powstania niniejszego modelu była chęć doprecyzowania modelu RBAC
w celu jawnego określenia, w jaki sposób działające w systemie podmioty mogą
mieć dostęp do obiektów. Ponadto, ponieważ w modelu RBAC nie ma mowy o
obiektach, nie ma rozwiniętych żadnych mechanizmów ułatwiających administrowa-
nie przydzielaniem praw do poszczególnych obiektów. Oczywiste jest, że potrzebne
są konstrukcje ułatwiające to zadanie, gdyż w przypadku systemu, w którym ilość
obiektów z danymi liczona jest w dziesiątkach tysięcy, bez zarządzania na wyższym
poziomie abstrakcji system przestaje być praktycznie funkcjonalny. Jednocześnie
wprowadzony model powinien być możliwie ogólny, stanowić raczej pewne ramy,
które mogą być modyfikowane i precyzowane w miarę potrzeb konkretnego zasto-

sowania. Dlatego też do modelu wprowadzono pojęcie domen, czyli wyróżnionych
podzbiorów zbioru obiektów. Prawa, jakimi dysponują role nie są teraz prawami do
poszczególnych obiektów, ale do całych domen. Prawa do konkretnego obiektu są
sumą praw, jakimi dysponuje rola do wszystkich domen zawierających ten obiekt.
Dzięki temu administrowanie prawami do obiektów jest podzielone na dwa etapy,
przypisanie obiektów do właściwych im domen i ustalenie, jakie prawa mają role do
poszczególnych domen. Bardziej szczegółowa analiza pomysłu grupowania obiektów
w kontekście mechanizmów kontroli dostępu została przedstawiona w [41].

5.1.1

Elementy składowe

Podstawowymi elementami modelu są użytkownicy, obiekty, i podmioty oraz prawa,
role i domeny. Większość z nich ma znaczenie takie, jak w klasycznych modelach
RBAC czy DAC.

Użytkownicy reprezentują ludzi bądź pewne autonomiczne mechanizmy korzy-

stające z systemu w określonym celu. Zbiór użytkowników oznaczymy przez U.

Obiekty są pasywnymi elementami systemu, których zadaniem jest przechowy-

wanie danych. Przykładami obiektów są pliki. Zbiór obiektów w systemie oznaczymy
przez O.

Podmioty są aktywnymi elementami systemu, których zadaniem jest przetwa-

rzanie informacji, a co za tym idzie modyfikacja stanu innych obiektów lub pod-
miotów. Podmioty można rozumieć jako działające procesy. Podmioty działają „w
imieniu” użytkownika, tzn. każdy podmiot ma użytkownika, z którego inicjatywy
powstał dany podmiot. Zbiór podmiotów będziemy oznaczać przez S.

W systemie mogą być określone różnego rodzaju prawa, jakie może mieć podmiot

do obiektu.

Prawa określają, jakiego typu operacje może wykonać podmiot na obiekcie.

Zazwyczaj do praw zalicza się czytanie, pisanie, dopisywanie, tworzenie, usuwa-
nie i inne. Możliwy zbiór praw zależy od przeznaczenia konkretnego systemu. W
naszym wypadku zbiór praw składa się z dwóch rozłącznych podzbiorów, zbioru
praw plikowych (a więc praw określających możliwe do wykonania operacje plikowe)
oznaczonego przez P

oraz zbioru praw administracyjnych, określających prawa do

zmiany parametrów mechanizmu kontroli dostępu takich jak zbiory użytkowników,
domen czy ról. Zbiór praw administracyjnych oznaczymy przez P

. Ostatecznie,

= P

∪ P

Role są pojęciem pozwalającym opisać, jakie zadania ma pełnić użytkownik

i pozwalającym na przypisanie praw potrzebnych do wykonania tych zadań. Zbiór
ról oznaczymy przez R.

Zupełnie nowym pojęciem modelu są domeny. Służą one do wyróżniania grup

obiektów o wspólnym przeznaczeniu lub właściwościach. Domena to po prostu wy-
różniony zbiór obiektów. Zbiór domen oznaczymy przez D.

5.1.2

Powiązania pomiędzy elementami

Właściwym jądrem modelu są powiązania, jakie występują pomiędzy elementami
składowymi modelu i realizują jego funkcjonalność.

Każdy użytkownik może mieć przydzielony pewien zestaw ról. Jest to realizowane

za pomocą funkcji

: U → 2

(5.1)

która użytkownikowi u przyporządkowuje pewien podzbiór R ⊆ R ról, które pełni
ten użytkownik w systemie.

Symetrycznie, każdy obiekt należy do pewnej ilości domen, określa to funkcja

: O → 2

(5.2)

która dla obiektu o ∈ O podaje podzbiór domen D ⊆ D do których należy ten
obiekt.

Istnienie każdego procesu jest inicjowane przez pewnego użytkownika, zatem dla

każdego podmiotu systemu określamy, na rzecz którego użytkownika działa dany
podmiot. W modelu realizowane jest to za pomocą funkcji

: S → U,

(5.3)

która zwraca użytkownika na rzecz którego działa podmiot. Zauważmy, że ponieważ
podmiot działa na rzecz pewnego użytkownika, można powiedzieć, że przynależą
mu się role, które pełni użytkownik za niego odpowiedzialny. Zatem zestaw ról, z
których może skorzystać podmiot s określony jest jako

(c(s)).

(5.4)

Fundamentalne znaczenie ma funkcja, która parom (rola, domena) przyporząd-

kowuje zestaw praw plikowych. Jest to funkcja

: R × D → 2

(5.5)

która określa zestaw praw, jakimi dysponuje dana rola do danej domeny. Zmiana
tej funkcji oznacza wpływ na konfigurację mechanizmu kontroli dostępu.

W podobny sposób określamy funkcję, która dla każdej roli określa podzbiór

praw administracyjnych. Zauważmy, że prawa administracyjne nie są bezpośred-
nio związane z jakąś domeną czy plikiem, a zatem są one przyporządkowane tylko
określonej roli. Jest to realizowane za pomocą funkcji

: R → 2

(5.6)

Użytkownik może mieć wiele ról, a obiekt może należeć do kilku domen, dlatego

trzeba jeszcze zdefiniować funkcję, która będzie zbiorom ról i zbiorom domen przy-
porządkowywać zbiory praw. Naturalne wydaje się sumowanie praw po wszystkich
rolach i domenach, zatem rozważać będziemy funkcję

: 2

→

(5.7)

gdzie

(R, D) =

[

∈R

[

∈D

(r, d).

(5.8)

We wzorze tym sumowanie odbywa się po wszystkich rolach r ∈ R. Dla każdej roli
r

znajdowana jest suma praw plikowych po wszystkich domenach, do których dana

rola ma jakieś uprawnienia.

Mając powyższe wzory, prawa plikowe podmiotu do obiektu określamy jako pra-

wa, które wynikają z praw ról użytkownika podmiotu do domen, w których znajduje
się obiekt. Mamy więc do czynienia z funkcją dostępu

: S × O → 2

określoną dla s ∈ S i o ∈ O jako

(s, o) = H

(%(c(s)), δ(o)).

(5.9)

Dodatkowo, każdemu podmiotowi przyporządkowane mogą być pewne prawa ad-
ministracyjne w zależności od przydzielonego mu podzbioru ról. Są one określone
jako

(s) =

[

∈%(c(s))

(r).

(5.10)

Ostatecznie, aktualna konfiguracja systemu ochrony określona jest poprzez szóstkę

(U, R, D, O, A, H

(5.11)

Działanie modelu (uwzględniające tylko prawa plikowe) obrazuje rysunek 5.1. Bio-
rąc pod uwagę powiązania przedstawione na rysunku, podmiotowi s

przysługują

prawa {r, w} do obiektu o

, gdyż właścicielem podmiotu jest użytkownik u

z przy-

dzielonymi rolami r

, r

. Rola r

ma przyporządkowane prawo r do obiektów domeny

, a rola r

ma przyporządkowane prawa {r, w} do obiektów domeny D

(w tym

właśnie o

Rysunek 5.1. Ilustracja powiązań między elementami w proponowanym modelu

Na tej samej zasadzie podmiot s

ma do obiektu o

tylko prawo czytania r, gdyż

użytkownik u

ma przyporządkowaną rolę r

, a ta z kolei pozwala czytać z obiektów

znajdujących się w domenie D

5.2

Analiza cech modelu

Pierwszą cechą modelu odróżniającą go od RBAC jest jawne występowanie w nim
pojęcia obiektów systemu rozumianych tak, jak w modelach DAC czy MAC.

Nowe pojęcie domen uogólnia klasyczny model RBAC. Jeżeli bowiem dla każ-

dego obiektu systemu tworzylibyśmy odpowiadającą mu domenę zawierającą tylko
ten obiekt, otrzymalibyśmy symulację zwykłego modelu RBAC. Jednak poprzez gru-
powanie obiektów w domeny uzyskujemy możliwość przydzielania praw do całych
zbiorów obiektów jednocześnie.

W wielu systemach istnieje taka możliwość bazująca na dziedziczeniu przez plik

praw z katalogu, w którym się znajduje. Jest to również szczególny przypadek podej-
ścia domenowego, w którym z każdym katalogiem związana jest domena określająca
prawa do plików w katalogu. Jednak proponowane podejście, które zakłada odse-
parowanie grup plików od fizycznej struktury katalogów ma tą zaletę, że pozwala
na łączne manipulowanie prawami do plików, które często muszą znajdować się w
różnych katalogach.

W przedstawionym modelu nie ma rozróżnienia na „zwykłe” role i role admi-

nistracyjne. Każda rola może mieć przyporządkowane prawa administracyjne. Pod
względem funkcjonalności, jest to podejście równoważne zastosowanemu w RBAC,
gdyż każdą rolę modelu domenowego można symulować w modelu RBAC za pomocą
pary ról: zwykłej i administracyjnej, natomiast rola czy rola administracyjna RBAC
jest po prostu rolą modelu domenowego.

Wyróżnienie w RBAC ról administracyjnych spowodowane było wprowadzonym

mechanizmem hierarchizacji ról oraz ograniczeń. Ponieważ w naszym modelu nie
rozważamy tego typu konstrukcji, skłaniając się raczej ku wersji modelu przystoso-
wanej do ewentualnego użycia negatywnych praw, nie było potrzebne uwzględnianie
wymagań stawianych przez te mechanizmy.

Ważnym zagadnieniem jest złożoność obliczeniowa podstawowej operacji syste-

mu, jaką jest obliczenie efektywnych praw podmiotu do obiektu.

Mając dany podmiot, znalezienie jego właściciela (za pomocą funkcji określonej

wzorem 5.3) można dokonać w czasie stałym. Prawa plikowe obliczamy zgodnie ze
wzorem 5.8, sumując po wszystkich rolach i domenach. Najgorszym przypadkiem
jest możliwość, gdy dany użytkownik pełni wszystkie role a obiekt znajduje się we
wszystkich domenach. Pesymistyczna złożoność procesu obliczenia praw wynosi więc

· n

gdzie n

jest ilością ról, a n

jest ilością domen. Podczas znajdowania zbioru praw

administracyjnych sumujemy tylko po rolach, zatem złożoność tego procesu wynosi
O

5.3

Projekt i implementacja systemu

W celu praktycznego zbadania użyteczności zdefiniowanego modelu został on użyty
jako podstawa wirtualnego systemu plików. System ten pracując w architekturze
klient–serwer udostępnia usługę zdalnego przechowywania plików i współdzielenia
ich z innymi użytkownikami systemu.

Zdecydowano się na implementację w języku Java [20], [61], [14], wysokopo-

ziomowym, udostępniającym w pełni obiektowe podejście oraz wiele wygodnych
mechanizmów służących tworzeniu oprogramowania zorientowanego sieciowo.

5.3.1

Odwzorowanie elementów modelu w klasy

System został zaprojektowany obiektowo, jako zbiór współdziałających ze sobą klas
reprezentujących logicznie odrębne części programu. Obrazuje to rysunek 5.2.

Klasa FSServer reprezentuje serwer usługi, który po uruchomieniu oczekuje na

ustalonym porcie na przychodzące połączenia. Po nawiązaniu połączenia tworzony
jest nowy obiekt klasy FSSession. Jego pierwszym zadaniem jest uwierzytelnienie
łączącego się klienta. Gdy powiedzie się ono, obiekt ten reprezentujący podmiot
modelu może interpretować przychodzące przez sieć polecenia i przekładać je na od-
powiednie wywołania metod klasy FileSystem. W przypadku, gdy uwierzytelnienie
nie powiedzie się, połączenie sieciowe jest zamykane a obiekt jest niszczony.

Najważniejszym elementem systemu zawierającym cały mechanizm kontroli do-

stępu jest klasa FileSystem, która udostępnia interfejs pozwalający na posługiwanie
się mechanizmem kontroli dostępu. Oddziela ona zbiór obiektów systemu (plików),
od podmiotów które chcą mieć do nich dostęp i w zależności od konfiguracji sys-
temu ochrony (zbiory zarejestrowanych użytkowników, domen, ról i odpowiednich
przypisań użytkownicy – role i role – domeny – prawa) decyduje, pozytywnie czy
negatywnie odpowiedzieć na żądanie dostępu do danych.

FileSystem

FSServer

FSSession

FSClient

komunikacja

przez sieæ

nawi¹zanie po³¹czenia

kontrolowane wywo³ania

metod intefejsu

bezpoœredni dostêp

do danych

stworzenie

sesji

FSObjects

Rysunek 5.2. Schemat działania systemu z uwzględnieniem najważniejszych klas

Elementy teoretycznego modelu takie jak użytkownik, domena, rola, zbiór upraw-

element modelu odwzorowująca klasa

obiekt

FSObject

domena

FSDomain

rola

FSRole

zbiór praw

FSPermission

podmiot

FSSession

użytkownik

FSUser

Tabela 5.1. Odpowiedniość pomiędzy elementami modelu a klasami programu

nień zostały bezpośrednio odwzorowane na klasy, co przedstawia tabela 5.1. Więk-
szość z nich jest używana jedynie w klasie FileSystem. Wyjątkiem jest FSUser,
który służy również do identyfikowania, na rzecz jakiego użytkownika stworzono
daną sesję.

Podejście takie zapewnia przejrzystość kodu a także odpowiednią elastyczność na

potrzeby przyszłej rozbudowy systemu. Jeżeli okaże się, że któryś element systemu
nie odpowiada rzeczywistym potrzebom, wystarczy zmienić implementację jednej
klasy, reszta programu nie będzie wymagała poprawek.

5.3.2

Niektóre zagadnienia implementacyjne

Przedstawimy teraz niektóre techniczne rozwiązania zastosowane podczas imple-
mentowania opisanego wyżej modelu.

Główny mechanizm kontroli dostępu zaimplementowany został w klasie o nazwie

FileSystem

. Zawiera ona kolekcje istniejących w systemie ról, domen i zarejestrowa-

nych użytkowników w postaci map hashowych, gdzie kluczami są nazwy elementów.
W przypadku, gdy wywoływana jest jedna z metod dostępu do plików, na rzecz
użytkownika FSUser wykonywana jest metoda getPermToObject(objName), gdzie

objName

oznacza nazwę pliku, do którego dostęp jest rozważany. Dla każdej roli,

której uczestnikiem jest użytkownik, sprawdza ona wszystkie domeny, do których
rola ma określony zestaw praw i sumuje je. Metoda ta jest odpowiednikiem wzo-
ru 5.9. Dzięki zastosowaniu kolekcji i iteratorów kod realizujący to zadanie jest
bardzo zwięzły.

public FSPermission getPermToObject(String objName) {

FSPermission perm = new FSPermission();

//dla wszystkich rol jakie pelni uzytkownik

Iterator it = myRoles.iterator();

while ( it.hasNext() ) {

FSRole r = (FSRole)it.next();

//teraz dla kazdej roli przegladamy domeny

Set dom = r.getDomains();

Iterator domIter = dom.iterator();

//dla wszystkich domen do ktorych ma jakies prawa biezaca rola

while ( domIter.hasNext() ) {

FSDomain d = (FSDomain) domIter.next();

//jezeli biezaca domena zawiera ten obiekt, dodajemy prawa

if (d.containsObject(objName))

perm.addPermissions(r.getPermissionsToDomain(d));

}

return perm;

}//getPermToObject

W podobny sposób zrealizowana jest druga kluczowa funkcja kontroli dostępu,

będąca odpowiednikiem wzoru 5.10, a podająca zestaw praw administracyjnych,
jakimi dysponuje dany użytkownik. Jest ona również metodą składową klasy FSUser
a jej kod ma następującą postać.

public FSPermission getAdmPermissions() {

FSPermission perm = new FSPermission();

Iterator it = myRoles.iterator();

while ( it.hasNext() ) {

FSRole r = (FSRole)it.next();

perm.addPermissions(r.getAdmPermissions());

}

return perm;

}//getAdmPermissions

Klasa FSPermission służy do przechowywania zbioru praw dostępu. Każdy pod-

zbiór praw dostępu można opisać jako sumę logiczną statycznych stałych zdefinio-
wanych w tej klasie. Stałe te oraz ich znaczenie zostały podane w Dodatku C. Sama
klasa dostarcza wygodnych metod „opakowujących”, dzięki którym można dokonać

porównania dwóch zbiorów praw (metoda equals), sprawdzić zawieranie (meto-
da contains) oraz dodać i odjąć podzbiory praw (metody addPermissions oraz

substractPermissions

Do komunikowania się poprzez sieć zdecydowano się użyć prostego protokołu

bazującego na przesyłaniu danych w postaci tekstowej. Dzięki takiemu rozwiąza-
niu zapewniona została możliwie duża swoboda co do realizacji klienta. Oczywiście
nowocześniejszym podejściem byłoby zastosowanie mechanizmu RMI [63], jednak
wtedy klient musiałby być również napisany w Javie, co mogłoby zawęzić grono
potencjalnych użytkowników.

Specyfikacja protokołu została zamieszczona w Dodatku A. Komunikacja odby-

wa się poprzez wymianę pomiędzy klientem a serwerem linii tekstu zakończonych
znakiem końca linii \n, podobnie jak ma to miejsce w protokołach typu NNTP [31].
Początkowo użytkownik jest uwierzytelniany, a następnie wydaje on polecenia, które
są wykonywane a ich wyniki są zwracane jako tekst, zgodnie z protokołem. Dane
binarne (zawartości transferowanych plików) są przekształcane do postaci zakodo-
wanej wg algorytmu base64 [7], dzięki czemu możliwe jest ich przesyłanie w postaci
tekstowej. Wykorzystano do tego celu klasy BASE64Decoder i BASE64Encoder z nie-
udokumentowanego pakietu sun.misc, których dokładniejszy opis można znaleźć
w [24].

Gromadzone przez serwer pliki z danymi są przechowywane jako normalne pli-

ki w określonym przy starcie serwera katalogu, do którego proces serwera ma do-
stęp. Cała reszta informacji na temat elementów systemu pliku musi być oczywiście
również przechowywana i odczytywana przy uruchamianiu usługi a zapamiętywana
przed zakończeniem pracy serwera. Zdecydowano się na zapis konfiguracji systemu
plików w postaci pliku XML [3], [25], dzięki czemu uzyskano przejrzysty i prosty
sposób zapisu danych, otwarty na ewentualny rozwój i modyfikację, a także pozwa-
lający na łatwą wizualizację stanu systemu plików. Zapis danych w XML, który
staje się standardem przechowywania danych, ułatwi również tworzenie zewnętrz-
nych programów wykorzystujących te dane, jak np. analizatora kanałów przepływu
informacji w systemie, który jako dane wejściowe wykorzysta plik XML. Dodatkową
zaletą jest również łatwość wykorzystania tego formatu w Javie, dzięki istniejącym
już interfejsom programistycznym [42].

W programie do analizy pliku XML przy wczytywaniu zastosowano klasy parsera

Xerces2

[1] dla języka Java w wersji 2.0.1, natomiast zapisywanie pliku odbywa się

poprzez mechanizm podobny do serializacji: każdy element systemu plików zapisuje

informację o sobie w postaci sekwencji XML do strumienia wyjściowego. Definicja
typu dokumentu (DTD) dla pliku konfiguracyjnego wraz z krótkim objaśnieniem
znajduje się w Dodatku B.

5.4

Kierunki dalszego rozwoju

Przedstawiony model i jego implementacja nie są oczywiście wersją finalną, a raczej
podstawą do dalszych prac nad mechanizmami kontroli dostępu.

Zasadniczym kierunkiem rozwoju jest przystosowanie mechanizmu kontroli do-

stępu do działania w środowisku rozproszonym, gdyż takie wymagania stawia obec-
nie rozwój nie tylko Internetu, ale również gwałtowna ekspansja coraz bardziej za-
awansowanych i uniwersalnych urządzeń przenośnych.

Niezbędne jest więc przede wszystkim wyposażenie mechanizmu w metody silne-

go uwierzytelniania, opartego na certyfikatach, gdyż bazowanie na przesyłaniu haseł
nie jest oczywiście rozwiązaniem bezpiecznym.

Do tej pory decyzja o przyznaniu bądź odmowie dostępu do określonego zaso-

bu odbywała się centralnie, poprzez odwołanie do serwera. Jednak przyznawanie
certyfikatów użytkownikom systemu pozwoliłyby na oparcie mechanizmu kontroli
dostępu o listy możliwości, wydawane przez uprawnione centra autoryzacji. Wów-
czas chronione zasoby mogłyby znajdować się nie na jednym, lecz wielu serwerach
wystawiających certyfikaty i wzajemnie ufających wydanym przez siebie listom moż-
liwości.

Kolejnym zadaniem jest również zapewnienie poufności transmitowanych danych

poprzez ich szyfrowanie. Najprostszym rozwiązaniem byłoby zastosowanie połączeń
poprzez gniazda SSL, jednak wtedy potrzebny już będzie specjalizowany klient.

Wówczas być może lepszym rozwiązaniem będzie nowa implementacja całego

modelu przystosowująca go do technologii RMI, gdzie szyfrowanie i deszyfrowanie
danych będzie realizowane w sposób przezroczysty w procesie serializacji i deseria-
lizacji.

Od strony teoretycznej, zaproponowany model, podobnie jak i modele RBAC,

wymaga pracy w kierunku przebadania cech bezpieczeństwa i wyodrębnienia kon-
strukcji bezpiecznych wg pewnych kryteriów. Istnieje potrzeba znalezienia algoryt-
mów i metod, dzięki którym będzie można oddzielać modele, których parametry
spełniają założenia konkretnych polityk bezpieczeństwa od tych, które nie są w sta-
nie zapewnić wymaganego poziomu bezpieczeństwa.

Bibliografia

[1] The Apache XML Project, Xerces2 Java Parser, strona internetowa

http://xml.apache.org/xerces2-j

[2] D.E. Bell, L.J. LaPadula, Secure Computer Systems: Mathematical foundations,

MTR-2547, (vol. I, II), MITRE Corp., Bedford, MA, 1973

[3] T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler (eds.), Extensible Markup

Language (XML) 1.0 (Second Edition) W3C Recommendation, Październik
2000

[4] M. Bishop, L. Snyder, The Transfer of Information and Authority in a Pro-

tection System, Proc. 7th Symp. on Operating Systems Principles, 1979, ss.
45-54

[5] M. Bishop, Conspiracy and Information Flow in the Take-Grant Protection

Model, Journal of Computer Security, vol. 4 nr 4, 1996, ss. 331-359

[6] L. S. Bobrow, M. A. Arbib, Discrete Mathematics: Applied Algebra for Com-

puter and Information Science, W.B.Saunders Company, 1974

[7] N. Borenstein, N. Freed, MIME (Multipurpose Internet Mail Extensions): Me-

chanisms for Specifying and Describing the Format of Internet Message Bodies,
Network Working Group, Request for Comments: 1341, Czerwiec 1992

[8] D.F. Brewer, M.J. Nash, The Chinese Wall Security Policy, Proc. IEEE Sym-

posium on Security and Privacy, ss. 215–228, 1989

[9] T.H. Cormen, C.E. Leiserson, R.L. Rivest, Wprowadzenie do algorytmów, Wy-

dawnictwa Naukowo–Techniczne, Warszawa 1998

[10] D.E. Denning, Secure information flow in computer systems, rozprawa doktor-

ska, Prudue University, CSD TR 145, 1975

[11] D.E. Denning, A Lattice Model of Secure Information Flow, Communications

of the ACM, vol. 19 nr 5, Maj 1976

[12] D.E. Denning, T.F. Lunt, R.R. Schell, M. Heckman and W. Shockley, The

SeaView Formal Security Policy Model, SRI Interim Report A003, SRI Inter-
national, 1987

[13] D.E. Denning, Kryptografia i ochrona danych, Wydawnictwa Naukowo–

Techniczne, Warszawa 1992

[14] B. Eckel, Thinking in Java. Edycja polska, Wydawnictwo Helion, 2001

[15] D. Ferraiolo, R. Kuhn, Role–Based Access Control, Proc. 15th National Com-

puter Security Conference, 1992

[16] M. R. Garey, D. S. Johnson, Computers and Intractability. A Guide to the

Theory of NP-Completness, W.H Freeman and Company, 1979

[17] S.I. Gavrila, J.F. Barkley, Formal Specification for Role Based Access Control

Uer/Role and Role/Role Relationship Management, Proc. of 3rd ACM Work-
shop on Role–Based Access Control, Fairfax, Virginia, Październik 1998

[18] L. Giuri, P. Iglio, A formal model for role-based access control with constra-

ints, Proc. of 9th IEEE Computer Security Foundations Workshop, Kenmare,
Ireland, Czerwiec 1996, ss. 136–145

[19] B. Goodheart, J. Cox, Sekrety magicznego ogrodu. UNIX System V Wersja 4

od środka, Wydawnictwa Naukowo–Techniczne, Warszawa 2001

[20] J. Gosling, B. Joy, G. Steele, The Java Language Specification, Addison Wesley

Developers Press, Sunsoft Java Series, 1996

[21] G.S. Graham, P.J. Denning, Protection – principles and practice, Proc. Spring

Jt. Computer Conf. vol.40, AFIPS Press, Montvale, N.J., 1972

[22] S. L. Graham, M. A. Harrison, W.L. Ruzzo, On-line context-free language re-

cognition in less than cubic time, Proc. Eighth Annual ACM Symposium on
Theory of Computing, 1976, ss. 112-120

[23] R. Grimm, B.N. Bershad, Providing Policy-Neutral and Transparent Access

Control in Extensible Systems, Secure Internet Programming, Lecture Notes in
Computer Science 1603, 1999

[24] E.R. Harold, Java Secrets, Hungry Minds, Inc. 1997

[25] E.R. Harold, XML. Księga eksperta Wydawnictwo Helion, 2000

[26] M.A. Harrison, W.L. Ruzzo, J.D. Ullman, Protection in Operating Systems,

Communications of the ACM, 19(8), 1976

[27] M.A. Harrison, W.L. Ruzzo, Monotonic protection systems, W: Foundations of

secure computation, R. D. Demillo et al., eds. Academic Press, New York 1978

[28] J.E. Hopcroft, J.D Ullman, Wprowadzenie do teorii automatów, języków i ob-

liczeń, Wydawnictwa Naukowe PWN, 1994

[29] A.K. Jones, Protection in programmed systems, rozprawa doktorska, Carnegie–

Mellon University, 1973

[30] A.K. Jones, R.J. Lipton, L. Snyder, A linear time algorithm for deciding secu-

rity, Proc. 17th Annual Symp. on Foundations of Computer Science, 1976

[31] B. Kantor, P. Lapsley, Network News Transfer Protocol. A Proposed Standard

for the Stream-Based Transmission of News, Network Working Group, Request
for Comments: 977, Luty 1986

[32] M. Koch, L.V. Mancini, F. Parisi–Presicce, A Formal Model for Role–Based

Acces Control Using Graph Transformation, Proc. 6th European Symposium
on Research in Computer Security (ESORICS’2000), Tolouse, Francja, Lecture
Notes in Computer Science 1895, 2000

[33] B.W. Lampson, Protection, Proc. 5th Princeton Symp. of Info. Sci. and Syst.,

Marzec 1971, ss.437-443

[34] B.W. Lampson, Computer Security, W: Computer At Risk, National Academy

Press, 1990

[35] C. Landwehr, C. Heitmeyer, J. McLean, A Security Model for Military Message

System, ACM Transactions on Computer Systems, vol. 2, nr. 3, Sierpień 1984
ss. 198–222

[36] E.L. Leiss, Principles of Data Security, Plenum Press, 1982

[37] R.J. Lipton, T.M. Budd, On classes of protection systems, w: Foundations of

secure computation, R. D. Demillo et al., eds. Academic Press, New York 1978

[38] R.J. Lipton, L. Snyder, On synchronization and security, W: Foundations of

secure computation, R. D. Demillo et al., eds. Academic Press, New York 1978

[39] J. Majewski, Automaty i języki formalne, skrypt wykładu, strona internetowa

http://galaxy.uci.agh.edu.pl/~majew/

[40] K. Matusiewicz, Models and analysis of security in computer networks Proc.

2nd Int. Conf. on New Electrical and Electronic Technologies and Their Indu-
strial Implementation (NEET’2001), Kazimierz Dolny, Luty 2001

[41] K. Matusiewicz, P. Urbanowicz, Management of data objects in access control

models based on roles, Trudy BSTU, Seria Matematyka, Fizyka i Informatyka,
Minsk 2002 (w druku)

[42] B. McLaughlin, Java i XML, Wydawnictwo Helion, 2001

[43] J. McLean, A Comment on the ’Basic Security Theorem’ of Bell and LaPadula,

Information Processing Letters, vol. 20, no. 2, 1985

[44] J. McLean, Reasoning about Security Models, Proc. 1987 IEEE Symposium on

Security and Privacy, IEEE Computer Society Press, 1987

[45] J. McLean, The Algebra of Security, Proc. 1988 IEEE Symposium on Security

and Privacy, IEEE Computer Society Press, Kwiecień 1988

[46] J. McLean, The Specification and Modeling of Computer Security, IEEE Com-

puter, 23(1):9–16, Styczeń 1990

[47] Q. Munawer, Administrative Models for Role–Based Access Control , rozprawa

doktorska, George Mason University, 2000

[48] National Institute of Standards and Technology, NIST Role–Based Access Con-

trol, serwis internetowy: http://csrc.nist.gov/rbac/

[49] M. Nyanchama, S. Osborn, Information Flow Analysis in Role–Based Security

Systems, Proc. of 6th International Conference on Computing and Information,
Peterborough, Ontario, Kanada, Maj 1994

[50] S. Osborn, R. Sandhu, Q. Munawer, Configuring Role–Based Access Control to

Enforce Mandatory and Discretionary Access Control Policies,

[51] J. Pieprzyk, Fundamentals of Computer Security (draft)

[52] G. Rozenberg (ed.), Handbook of Graph Grammars and Computing by Graph

Transformations. Vol. I: Foundations, World Scientific, 1997

[53] R.S. Sandhu, The Typed Access Matrix Model, Proc. of IEEE Symposium on

Security and Privacy, 1992

[54] R. Sandhu, Lattice-based Enforcement of Chinese Walls, Computers and Secu-

rity, listopad 1992, ss. 753–763

[55] R. Sandhu, V. Bhamidipati, The URA97 Model for RolaBased User-Role Assi-

gnment, Proc. of IFIP WG 11.3 Workshop on Database Security, Lake Tahoe,
California, Sierpień 1997

[56] R. Sandhu, V. Bhamidipati, Q. Munawer, The ARBAC97 model for role-based

administration of roles, ACM Transactions on Information and System Security,
vol. 2 nr 1 ss. 105–135, 1999

[57] R. Sandhu, E.J. Coyne, H.L. Feinstein, Ch.E. Youman, Role–Based Access Con-

trol Models, IEEE Computer, Vol. 29, No. 2, Luty 1996

[58] R. Sandhu, Q. Munawer, The ARBAC99 Model for Administration of Roles,

Proc. of XIV Annual Computer Security Conference, Radisson Resort Scotts-
dale, Phoenix, Arizona, Grudzień 1999

[59] L. Snyder, Theft and conspiracy in TakeGrant model, Journal of Computer and

Systems Sciences, vol. 23 nr 3, 1981, ss. 337-347

[60] M. Soshi, Safety Analysis of the Dynamic-Typed Access Matrix Model, Proc. of

6th European Symposium on Research in Computer Security, Lecture Notes in
Computer Science 1895, 2000

[61] Sun Microsystems, java.sun.com-The Source for Java Technology, strona inter-

netowa http://java.sun.com

[62] L.G. Valiant, General context free recognition in less than cubic time, Journal

of Computer and Systems Sciences, vol. 10, nr 2, 1975 ss. 308-315

[63] A. Wollarth, J. Waldo, The Java Tutorial. Trail: RMI, strona internetowa

http://java.sun.com/docs/books/tutorial/rmi/

[64] D. H. Younger, Recognition and parsing of context-free languages in time n

Information and Control, vol. 10, nr 2, 1967, ss. 189-208

Dodatki

A. Specyfikacja protokołu komunikacyjnego

Poniżej przedstawiona jest specyfikacja protokołu komunikacyjnego używanego przez
program.

Protokół ten bazuje na wymianie informacji w postaci ciągów znaków ASCII.

Każda linia zakończona jest znakiem nowego wiersza \n. Składnia elementów poleceń
w notacji BNF jest następująca:

<litera> := a..zA..Z

<cyfra> := 0..9

<znakhex> := 0..9A..F

<spacja> :=

<ciag_znakow> := <znak>[<znak>]

<ciag_znakow_ze_sp> := <znak>|<spacja>[<znak>|<spacja>]

<fileName> := <ciag_znakow>|"<ciag_znakow_ze_sp>"

<domainName> := <ciag_znakow>|"<ciag_znakow_ze_sp>"

<roleName> := <ciag_znakow>|"<ciag_znakow_ze_sp>"

<userName> := <ciag_znakow>|"<ciag_znakow_ze_sp>"

Polecenia dostępne w protokole dzielą się na następujące grupy:

1. polecenie logowania (LOGIN)

2. polecenia tworzenia (CREATE)

CREATE FILE <fileName> IN <domainName>

CREATE DOMAIN <domainName>

CREATE ROLE <roleName>

CREATE USER <userName>

3. polecenia kasowania (DELETE)

DELETE FILE <fileName>

DELETE DOMAIN <domainName>

DELETE ROLE <roleName>

DELETE USER <userName>

4. polecenia dodawania (ADD)

ADD ROLE <roleName> TO <userName>

ADD FILE <fileName> TO <domainName>

ADD PERM <permSpec> <domainName> TO <roleName>

ADD ADMPERM <permSpec> TO <roleName>

5. polecenia usuwania (REMOVE)

REMOVE ROLE <roleName> FROM <userName>

REMOVE FILE <fileName> FROM <domainName>

REMOVE PERM <permSpec> <domainName> FROM <roleName>

REMOVE ADMPERM <permSpec> FROM <roleName>

6. polecenia obsługi danych (FILE)

FILE READ <fileName>

FILE WRITE <fileName>

FILE APPEND <fileName>

7. polecenia wypisywania (LIST)

LIST FILES <domainName>

LIST ROLES <userName>

LIST DOMAINS

Poniżej przedstawione są informacje jakie wymieniają między sobą użytkownik

(U) i serwer (S) w trakcie wykonywania poleceń. Symbole w nawiasach trójkątnych
oznaczają parametry wykonywanego polecenia. Znak | oznacza alternatywę kilku
możliwych odpowiedzi. Pojawienie się jednej z nich zależy od sytuacji.

1.1 polecenie LOGIN

========================

U: LOGIN <userName>

S: OK send password

U: <password>

S: OK user authenticated | ERROR bad username or password

S: <zakończenie połączenia>

2.1 polecenie CREATE FILE

========================

U: CREATE FILE <fileName> IN <domainName>

S: OK empty file created | ERROR <domainName> does not exist

| ERROR <fileName> already exists

| ERROR no permission

2.2 polecenie CREATE DOMAIN

========================

U: CREATE DOMAIN <domainName>

S: OK domain created | ERROR <domainName> already exists

| ERROR no permission

2.3 polecenie CREATE ROLE

========================

U: CREATE ROLE <roleName>

S: OK role created | ERROR <roleName> already exists

| ERROR no permission

2.4 polecenie CREATE USER

========================

U: CREATE USER <userName>

S: OK enter fullname

U: <fullName>

S: OK enter password

U: <password>

S: OK user <userName> created | ERROR <userName> already exists

| ERROR no permission

3.1 polecenie DELETE FILE

========================

U: DELETE FILE <fileName>

S: OK file deleted | ERROR <fileName> does not exist

| ERROR no permission to delete file

3.2 polecenie DELETE DOMAIN

========================

U: DELETE DOMAIN <domainName>

S: OK domain deleted | ERROR <domainName> does not exist

| ERROR no permission

3.3 polecenie DELETE ROLE

========================

U: DELETE ROLE <roleName>

S: OK role deleted | ERROR <roleName> does not exist

| ERROR no permission

3.4 polecenie DELETE USER

========================

U: DELETE USER <userName>

S: OK user deleted | ERROR <userName> does not exist

| ERROR no permission

4.1 polecenie ADD ROLE

========================

U: ADD ROLE <roleName> TO <userName>

S: OK role assigned | ERROR <roleName> does not exist

| ERROR <userName> does not exist

| ERROR no permission

4.2 polecenie ADD FILE

========================

U: ADD FILE <fileName> TO <domainName>

S: OK file added | ERROR <fileName> does not exist

| ERROR <domainName> does not exist

| ERROR no permission

4.3 polecenie ADD PERM

========================

U: ADD PERM <permSpec> <domainName> TO <roleName>

S: OK permission added | ERROR bad <permSpec>

| ERROR <domainName> does not exist

| ERROR <roleName> does not exist

| ERROR no permission

4.4 polecenie ADD ADMPERM

========================

U: ADD ADMPERM <permSpec> TO <roleName>

S: OK permission added | ERROR bad <permSpec>

| ERROR <roleName> does not exist

| ERROR no permission

5.1 polecenie REMOVE ROLE

========================

U: REMOVE ROLE <roleName> FROM <userName>

S: OK role removed | ERROR <roleName> does not exist

| ERROR <userName> does not exist

| ERROR no permission

5.2 polecenie REMOVE FILE

========================

U: REMOVE FILE <fileName> FROM <domainName>

S: OK file removed from domain | ERROR <fileName> does not exist

| ERROR <domainName> does not exist

| ERROR no permission

5.3 polecenie REMOVE PERM

=========================

U: REMOVE PERM <permSpec> <domainName> FROM <roleName>

S: OK permission removed | ERROR bad <permSpec>

| ERROR <domainName> does not exist

| ERROR <roleName> does not exist

| ERROR no permission

5.4 polecenie REMOVE ADMPERM

========================

U: REMOVE ADMPERM <permSpec> FROM <roleName>

S: OK permission removed | ERROR bad <permSpec>

| ERROR <roleName> does not exist

| ERROR no permission

6.1 polecenie FILE READ

========================

U: FILE READ <fileName>

S: OK file follows | ERROR <fileName> does not exist

| ERROR no permission

S: <ciąg linii będących zakodowanymi BASE64 danymi>

6.2 polecenie FILE WRITE

========================

U: FILE WRITE <fileName>

S: OK waiting for data | ERROR <fileName> does not exist

| ERROR no permission

U: <ciąg linii będących zakodowanymi BASE64 danymi>

6.3 polecenie FILE APPEND

=======================

U: FILE APPEND <fileName>

S: OK waiting for data | ERROR <fileName> does not exist

| ERROR no permission

U: <ciąg linii będących zakodowanymi BASE64 danymi>

7.1 polecenie LIST FILES

========================

U: LIST FILES <domainName>

S: OK sending list | ERROR <domainName> does not exist

| ERROR no permission

S: <fileName>

S: ....

S: <fileName>

S: <pusta linia>

7.2 polecenie LIST ROLES

========================

U: LIST ROLES <userName>

S: S: OK sending list | ERROR <userName> does not exist

| ERROR no permission

S: <roleName>

S: ....

S: <roleName>

S: <pusta linia>

7.3 polecenie LIST DOMAINS

========================

U: LIST DOMAINS

S: S: OK sending list | ERROR no permission

S: <domainName>

S: ....

S: <domainName>

S: <pusta linia>

B. Definicja DTD i opis pliku konfiguracji

Definicja typu dokumentu dla pliku przechowującego dane o konfiguracji systemu
plików jest następująca.

<!DOCTYPE FILESYSTEM [

<!ELEMENT FILESYSTEM (DOMAIN*,ROLE*,USER*)>

<!ELEMENT DOMAIN(FILE*)>

<!ATTLIST DOMAIN name CDATA #REQUIRED>

<!ELEMENT FILE (#PCDATA)>

<!ELEMENT ROLE (PERMTODOMAIN*,ADMPERM?)>

<!ATTLIST ROLE name CDATA #REQUIRED>

<!ELEMENT PERMTODOMAIN (#PCDATA)>

<!ATTLIST PERMTODOMAIN domainname CDATA #REQUIRED>

<!ELEMENT ADMPERM (#PCDATA)>

<!ELEMENT USER (FULLNAME,HASHPASS,ASSIGNEDROLE*)>

<!ATTLIST USER name CDATA #REQUIRED>

<!ELEMENT FULLNAME (#PCDATA)>

<!ELEMENT HASHPASS (#PCDATA)>

<!ELEMENT ASSIGNEDROLE (#PCDATA)>

Oznacza ona, że głównym elementem pliku jest znacznik FILESYSTEM, który następ-
nie zawiera w sobie ciąg znaczników DOMAIN, potem ciąg znaczników ROLE, a na
końcu znaczniki USER.

Każdy znacznik DOMAIN musi mieć atrybut name oznaczający nazwę domeny, a

zawiera w sobie ciąg znaczników FILE które zawierają nazwy plików przyporządko-
wanych domenie.

Każdy znacznik ROLE musi mieć atrybut name oznaczający nazwę roli, a zawiera

w sobie ciąg znaczników PERMTODOMAIN opisujących prawa do określonej domeny
oraz opcjonalnie na końcu jeden znacznik ADMPERM opisujący prawa administracyjne
oraz prawa do domeny uniwersalnej.

Każdy znacznik PERMTODOMAIN musi posiadać atrybut domainname określający

nazwę domeny do jakiej odnoszą się prawa a zawiera ciąg cyfr szesnastkowych re-
prezentujących prawa dostępu do plików w domenie.

Znacznik ADMPERM zawiera ciąg cyfr szesnastkowych reprezentujących admini-

stracyjne prawa dostępu oraz prawa plikowe do domeny uniwersalnej.

Każdy znacznik USER musi mieć atrybut name oznaczający identyfikator użyt-

kownika. Wewnątrz tego znacznika musi zawierać się po jednym: znacznik FULLNAME,
znacznik HASHPASS a potem ciąg znaczników ASSIGNEDROLE.

Znacznik FULLNAME zawiera w sobie ciąg znaków opisujących imię i nazwisko

użytkownika.

Znacznik HASHPASS przechowuje ciąg cyfr szesnastkowych opisujących zaszyfro-

wane za pomocą algorytmu SHA-1 hasło użytkownika.

Każdy znacznik ASSIGNEDROLE musi zawierać ciąg znaków opisujący nazwę roli

którą pełni dany użytkownik.

Przykładowy zapis konfiguracji systemu zamieszczony jest poniżej.

<?xml version="1.0" standalone="yes" encoding="ISO-8859-2"?>

<FILE>dokument.doc</FILE>

<FILE>hobbit.pdf</FILE>

</DOMAIN>

</ROLE>

</ROLE>

<FULLNAME>wbudowany administrator</FULLNAME>

<HASHPASS>E203CADB3AAFCC78216784F1B245BFBCEDD314F3</HASHPASS>

<ASSIGNEDROLE>AdminRole</ASSIGNEDROLE>

</USER>

<FULLNAME>Krystian Matusiewicz</FULLNAME>

<ASSIGNEDROLE>czytelnik</ASSIGNEDROLE>

</USER>

</FILESYSTEM>

C. Rodzaje praw dostępu w klasie FSPermission

Poniżej podane są rodzaje praw dostępu zdefiniowane jako statyczne stałe w klasie

FSPermission

. Tekstowa reprezentacja używana w protokole sieciowym to łańcuch

pięciu cyfr szesnastkowych oznaczający liczbę będącą sumą praw należących do
zbioru.

nazwa stałej

wartość prawo pozwala na

canNothing

0x00000

–

canReadFile

0x00001

czytanie zawartości pliku

canWriteFile

0x00002

pisanie do pliku

canAppendFile

0x00004

dopisywanie na końcu pliku

canCreateFile

0x00008

tworzenie plików w domenie

canDeleteFile

0x00010

kasowanie plików w domenie

canListFiles

0x00020

wypisanie nazw obiektów w domenie

allFilePerm

0x0003F

wszystkie operacje plikowe

canCreateDomain

0x00040

tworzenie nowych domen

canDestroyDomain

0x00080

usuwanie domen z systemu

canAddToDomain

0x00100

dodawanie obiektów do domeny

canRemoveFromDomain

0x00200

usuwanie domen z systemu

canListDomains

0x00400

czytanie, jakie domeny są w systemie

canCreateRole

0x00800

tworzenie nowych ról w systemie

canDestroyRole

0x01000

usuwanie ról z systemu

canAddToRole

0x02000

przypisywanie użytkowników do ról

canRemoveFromRole

0x04000

odwoływanie użytkowników z peł-
nienia ról

canListRoles

0x08000

wypisywanie ról istniejących w sys-
temie

canCreateUser

0x10000

tworzenie nowych użytkowników

canDeleteUser

0x20000

kasowanie użytkowników z systemu

canAddPerm

0x40000

dodawanie praw do roli

canRemovePerm

0x80000

usuwanie praw z roli

allAdmPerm

0xFFFC0

wszystkie operacje administracyjne

Wyszukiwarka

Podobne podstrony:
Dostęp do zasobów szkolnego serwera poprzez sieć Internet
lab2Zarzadzanie dostepem do zasobów przy wykorzystaniu grup
Podwarstwa kontroli dostępu do nośnika
Zasady zdalnego dostepu do zasobow teleinformatycznych GUGiK
Rodzice i ich wpływ na młodzież i przypisy, Dokumenty praca mgr
GMO i ich wpływ na żywność i środowisko
Algorytmy sumowania w metodzie spektrum odpowiedzi i ich wpływ na obliczaną odpowiedź budynku wysoki
TWSN parametry pracy narzędzia i ich wpływ na jakość powierzchni obrabianej
Koloidy glebowe i ich wpływ na właściwości gleby
Napoje gazowane na?zie sody i ich wpływ na zęby
7 Patogeny i ich wpływ na organizm człowieka
Zanieczyszczenia radioaktywne i ich wpływ na zdrowie człowieka, Studia, 1-stopień, inżynierka, Ochro
Więzi społeczne i ich wpływ na stan?zpieczeństwa lokalnego
2 nowe formy komnikacji ich wpływ na zmiany językowe (rozwój reklamy, tel kom, internet nowe gat
Algorytmy sumowania w metodzie spektrum odpowiedzi i ich wpływ na obliczaną odpowiedź budynku wysoki

więcej podobnych podstron