plik

Architektura systemu
operacyjnego Windows
NT

Przegląd systemu Windows NT 3.51

Najważniejsze elementy systemu opera-
cyjnego. Tryb jądra i tryb użytkownika.
Znaczenie poszczególnych warstw syste-
mu.

Składowe elementy Windows NT
Executive

W tym rozdziale weźmiemy pod lupę system
operacyjny i przyjrzymy się, jak jest zabezpie-
czony przed awarią układu, nieuprawnionym
dostępem i zniekształceniem danych. Omawia-
ne zagadnienia pozwolą lepiej zrozumieć zało-
żenia przyjęte przez projektantów Windows NT.
Przeanalizujemy wszystkie kluczowe elementy
systemu ze szczególnym uwzględnieniem ich
wzajemnego współdziałania. W pierwszej części
rozdziału skupimy się na architekturze Win-
dows NT 3.51, by następnie omówić zmiany
wprowadzone w wersji 4.0.

Elementy składające się na Windows NT
Executive oraz funkcje poszczególnych
komponentów

Zmiany wprowadzone w Windows NT
4.0

Zmiany wprowadzone do nowej wersji
systemu i ich znaczenie dla poprawy dzia-
łania systemu.

Zmiany w egzekutywie Windows NT
Executive

Wpływ poważnych zmian w Windows NT
Executive na działanie systemu operacyj-
nego.

Win32K Executive

Nowy element zawarty w Windows NT
4.0. Komponenty, które we wcześniej-
szych wersjach działały w warstwie użyt-
kownika.

Co się dzieje w czasie rejestracji
w systemie

Proces rejestracji w systemie ujęty jako
ciąg zdarzeń.

Część I Przegląd systemu ochrony Microsoft Windows NT

Architektura Windows NT 3.51

Windows NT w wersji 3.51 zbudowany jest według architektury „zmo-
dyfikowanego mikrojądra”. Składa się z dwóch głównych warstw: trybu
użytkownika (User mode) oraz trybu jądra (Kernel mode) (por. rysunek
3.1). Każda warstwa składa się z oddzielnych, ale współpracujących ze
sobą modułów. Taka struktura pozwala projektantom zmieniać elementy
systemu, bez oddziaływania na pozostałe składniki.

Rysunek 3.1

Tryb użytkownika
oraz tryb jądra jako
składniki systemu
operacyjnego Win-
dows NT.

Na obecnym etapie trudno jest szczegółowo analizować różne elementy
składające się na warstwę trybu jądra. Rozpoczniemy jednak od tego
trybu, gdyż tu ulokowane jest centrum usług systemu operacyjnego. Na
tym piętrze architektury realizowane są zadania niskiego poziomu, takie
jak planowanie wątków i synchronizacja mikroprocesora. Inne procesy,
jak administrowanie pamięcią wirtualną, realizowane są na warstwie
wyższej w trybie jądra użytkownika.

Warstwa trybu jądra

Warstwę trybu jądra można podzielić na trzy podstawowe części:

Architektura systemu operacyjnego Windows NT

Abstrakcyjna warstwa sprzętowa (HAL - Hardware Abstraction Layer) -
Pierwsza część jest odpowiedzialna za współpracę z fizyczną stroną
komputera.

Jądro (lub mikrojądro) - Druga część realizuje najważniejsze funkcje
systemu operacyjnego wykorzystywane przez komponenty trybu ją-
dra.

Komponenty wykonawcze - Trzecia część jest zbiorem składników,
z których każdy jest odpowiedzialny za implementację właściwej mu
usługi systemu operacyjnego. Przykładowo: kontroler wskaźników
bezpieczeństwa (Security Reference Monitor), implementuje system za-
bezpieczeń, a menedżer procesów we/wy (I/O Manager) zarządza
wszystkimi procesami wejścia/wyjścia przebiegającymi w systemie.
O wszystkich elementach wykonawczych będziemy się szczegółowo
uczyć w dalszej części rozdziału.

Wszystkie składniki tworzą wspólnie Windows NT Executive. Zanim
skoncentrujemy się na różnych warstwach systemu operacyjnego, po-
winniśmy sobie wyjaśnić powód takiej, a nie innej architektury Windows
NT.

Mikroprocesory, będące sercem każdego komputera, umożliwiają uru-
chomienie wątków. Wątki są wykonywane w kontekście procesów,
a każdy proces może uruchomić wiele wątków. Wątki są w istocie rzeczy
instrukcjami, które zlecają komputerowi, jak ma działać. Wątki wykony-
wane w ramach systemu operacyjnego pracują na różnych poziomach
uprawnień. Te, które odpowiadają za funkcjonowanie systemu, są waż-
niejsze od tych, które są uruchamiane przez aplikacje. Z tego powodu
wątki sterujące kodem systemu operacyjnego mają wyższy poziom
przywilejów, niż wątki sterujące kodem aplikacji. W ten sposób aplikacja
jest chroniona od niezamierzonego zawieszenia się systemu operacyjne-
go. Moduły wchodzące w skład Windows NT Executive są wszystkie
uruchamiane w trybie jądra, gdyż posiadają przywileje i zabezpieczenia
wyższego rzędu, niż uruchamiany przez nie kod.

Procesory rodziny Intelx86 obsługują cztery poziomy przywilejów, ozna-
czonych jako pierścienie o numerach od 0 do 3 (por. rysunek 3.2). Pier-
ścień 0 jest najwyższym poziomem uprawnień, w który są wyposażone
wątki sterujące systemem operacyjnym. Stanowi to skuteczne zabezpie-
czenie układu przed zakłóceniami, które mogą być generowane przez
aplikacje. Procesy aplikacji są uruchamiane z trzecim poziomem przywi-
lejów, co zapobiega ewentualnym szkodliwym oddziaływaniom na sys-
tem.

Część I Przegląd systemu ochrony Microsoft Windows NT

Rysunek 3.2

Tryb jądra i tryb użytkowni-
ka działają na różnych
poziomach uprawnień.

Wszystkie aplikacje uruchamiają swój kod w wydzielonej i izolowanej
przestrzeni adresowej, aby zabezpieczyć kody lub dane innych procesów.
Zanim nastąpi przejście od jednego procesu do drugiego, system opera-
cyjny zmienia tablice stron procesora, zatem procesy „nie widzą” się
wzajemnie.

Teraz przyjrzymy się z bliska szczegółom komponentów Windows NT
Executive.

Komponenty Windows NT Executive

Program wykonawczy zawiera moduły jądra systemu operacyjnego,
które sterują jego sercem. Każdy element ma do wykonania swoje własne,
specyficzne zadanie. Analizę komponentów, celem określenia ich zadań,
zaczniemy od centrum jądra, przechodząc kolejno coraz bardziej na ze-
wnątrz.

Abstrakcyjna warstwa sprzętowa (HAL)

Jedna z najważniejszych cech Windows NT polega na niezależności od
fizycznych rozwiązań komputera. Jest realizowana przez abstrakcyjną
warstwę sprzętową, umieszczoną w samym centrum warstwy trybu ją-
dra. Dzięki temu sterowniki urządzeń HAL mogą obsługiwać więcej niż
jedną platformę sprzętową. Niektóre fabryki komputerów rozprowadzają
dostosowaną do swojego produktu wersję HAL, która zapewnia wyższy
stopień zgodności między sprzedawanym urządzeniem a Windows NT.
W takim przypadku należy zainstalować nakładkę, aby zapewnić dobre
działanie systemu operacyjnego.

Architektura systemu operacyjnego Windows NT

Jądro

Każdy proces składa się co najmniej z jednego wątku. Każdy wątek jest
z kolei odpowiedzialny za oddzielną klasę czynności. Zadaniem jądra jest
planowanie, w jakiej kolejności poszczególne czynności będą miały do-
stęp do procesora. Sterowanie kolejnością wątków realizowane jest po-
przez poziomy priorytetów. Wątki o wyższym priorytecie są wykonywa-
ne przed wątkami o priorytecie niższym.

Jądro zajmuje 4 kB jednostek pamięci systemu nie podlegających stroni-
cowaniu; Oznacza to, że pamięć wykorzystywana przez jądro, nie może
być stronicowana i przenoszona na dysk. Kod, uruchamiany wewnątrz
jądra, nie podlega wydziedziczaniu, co oznacza, że nie może być prze-
rwany przez inny proces. Oba rozwiązania zapewniają stabilność modu-
łu jądra w systemie operacyjnym.

Menedżer obiektów

Zasoby systemu operacyjnego są reprezentowane przez abstrakcyjną
strukturę danych o nazwie obiekt. Obiekt może reprezentować cokolwiek
- od katalogu do wątku procesu. Każdy obiekt zawiera informację, która
umożliwia identyfikację jego opisu oraz metody jego udostępniania. Me-
nedżer obiektów steruje tworzeniem, usuwaniem i modyfikacją wszyst-
kich typów obiektowych w systemie operacyjnym Windows NT. Limituje
również wielkość zasobów kontrolowanych przez obiekty, zabezpiecza-
jąc system przed obniżeniem wydajności.

Oto kilka przykładów obiektów systemu operacyjnego:

Połączenia symboliczne

Porty

Wątki

Pliki

Katalogi

Semafory i zdarzenia

Aby uzyskać dostęp do obiektu znajdującego się pod kontrolą menedże-
ra, procesy wyposażane są we wskaźniki nazywane „uchwytami obiek-
tów”. Menedżer obiektów, nazywany czasem ogólną przestrzenią nazw
(global namespace), ma strukturę podobną do systemu plików. Moduł do-
starcza informacji o statusie różnych obiektów systemu operacyjnego
oraz jest odpowiedzialny za usuwanie z niego wszystkich zbędnych
obiektów.

Część I Przegląd systemu ochrony Microsoft Windows NT

Kontroler wskaźników bezpieczeństwa

Moduł służy do sterowania wewnętrznym bezpieczeństwem systemu;
zarządza dostępem, tworzeniem i usuwaniem wszystkich obiektów
w systemie. Swoje zadania wykonuje dzięki liście kontroli dostępu (ACL
- Access Control List), która jest skojarzona z każdym obiektem. (O liście
ACL powiemy niedługo nieco więcej.) Każdy obiekt zawiera elementy
o nazwie pozycje kontroli dostępu (ACE - Access Control Entries), a każda
z nich zawiera unikatowy identyfikator bezpieczeństwa użytkownika lub
grupy (SID - security ID). W chwili obecnej identyfikator SID jest unika-
tową liczbą generowaną przez system operacyjny, która jest przyporząd-
kowana każdemu użytkownikowi (i grupie) w domenie.

Aby umożliwić użytkownikowi dostęp do obiektów, kontroler wskaźni-
ków bezpieczeństwa współpracuje w procesie rejestracji z podsystemami
ochrony trybu użytkownika. Wynikiem wspólnej pracy jest przepustka
chronionego dostępu (SAT- Security Access Token) zawierająca identyfika-
tory (SID) użytkownika oraz wszystkich grup, do których należy. Każdo-
razowo, gdy użytkownik żąda dostępu do obiektu, kontroler porównuje
pozycje z przepustki z elementami listy kontroli dostępu obiektu. Jeśli
weryfikacja wypadnie pozytywnie, klient otrzymuje pozwolenie na ko-
rzystanie z zasobów, zgodnie z uprawnieniami opisanymi odpowiednią
pozycją kontroli dostępu.

Menedżer procesów

Moduł kieruje dwoma typami obiektów: procesami i wątkami. Procesy
posiadają zasoby i wątki umieszczone we własnej wirtualnej przestrzeni
pamięci. Wątki zawierają przynależne im: stos jądra, blok środowiskowy
oraz zbiór rejestrów. Menedżer procesów jest odpowiedzialny za two-
rzenie i usuwanie procesów oraz śledzenie wątków. Reguły tworzenia
oraz usuwania obiektów nie są określane przez moduł, ale pochodzą
z zewnątrz, od jednego z podsystemów trybu użytkownika. Moduł do-
starcza jedynie zbioru standardowych usług, dzięki którym różne pod-
systemy tworzą lub wykorzystują wątki.

Mechanizm lokalnego wywoływania procedur (Local Procedure
Call Facility)

Podsystemy tworzące architekturę środowiska Windows NT służą jako
serwery dla aplikacji uruchamianych w systemie, działając analogicznie
jak serwery aplikacji dla programów uruchamianych w środowisku sie-
ciowym. Mechanizm lokalnego wywoływania procedur jest równoważny
zasadom pracy zdalnych wywołań procedur (RPC - Remote Procedure
Calls) dostarczających usług komunikacyjnych klient/serwer. Różnica

Architektura systemu operacyjnego Windows NT

polega na tym, że LPCF jest zaimplementowany wewnątrz pojedynczego
systemu operacyjnego, do obsługi komunikacji między podsystemami
trybu użytkownika a aplikacjami. Moduł jest odpowiedzialny za zapew-
nienie mechanizmów komunikacyjnych między aplikacjami a składo-
wymi systemu.

Menedżer pamięci wirtualnej (Virtual Memory Manager)

Kolejny składnik jest odpowiedzialny za odwzorowywanie wirtualnych
adresów przestrzeni adresowej procesów na fizyczne strony pamięci
systemu komputerowego. Umożliwia to wątkom dostęp do należnych im
obszarów pamięci, bez naruszania przestrzeni wykorzystywanej przez
inne procesy. Moduł realizuje fizyczne rozmieszczenie stron pamięci
operacyjnej w sposób „zrozumiały” dla procesów.

Układ umożliwia również systemowi operacyjnemu korzystanie
z pamięci obszerniejszej od zainstalowanej na komputerze. Jeżeli fizyczna
pamięć komputera jest całkowicie wykorzystana, to najmniej ważne
z ostatnio używanych stron pamięci (LRU - Least Recently Used) są zapi-
sywane na dysk.

Menedżer procesów wejścia/wyjścia (I/O Manager)

Działanie tego modułu najlepiej jest porównać do pracy policjanta steru-
jącego ruchem. Zarządza bowiem wszystkimi funkcjami wejścia/wyjścia,
sterowników wszystkich urządzeń systemu. Swym działaniem obejmuje
w szczególności: sterowniki urządzeń komputera, adaptery sieciowe oraz
system plików. Sterowniki wszystkich działających w systemie urządzeń
wejścia/wyjścia mogą posługiwać się zapewnianym przez moduł inter-
fejsem. Aktualnie menedżer umożliwia pracę urządzeń na różnych po-
ziomach. Sterownik urządzenia we/wy wysokiego poziomu przesyła
wezwanie do sterownika niskiego poziomu, bez potrzeby zajmowania się
fizycznymi szczegółami urządzenia. Na przykład: redirektor sieciowy,
który jest sterownikiem wysokiego poziomu, może bezpośrednio przesy-
łać wezwanie do sieci, bez zajmowania się zasadami sterowania karty
ethernet. Przewaga wspólnego interfejsu polega również na możliwości
jednoczesnego korzystania z różnych urządzeń.

Sterowniki porozumiewają się, wykorzystując specjalną strukturę danych
o nazwie pakiet żądania (IRP- I/O Request Packet). Menedżer odbiera IRP
i przesyła go do odpowiedniego adresata. Wykorzystuje się do tego asyn-
chroniczne rozwiązania wejścia/wyjścia, umożliwiające aplikacji konty-
nuowania działania w

trakcie wykonywania operacji we/wy.

W rozwiązaniach synchronicznych działanie aplikacji zostaje zawieszone
do czasu pełnego zrealizowania żądania we/wy. Wszystkie żądania

Część I Przegląd systemu ochrony Microsoft Windows NT

we/wy są realizowane za pośrednictwem kolejki, przy czym o kolejności
decyduje priorytet, a nie pierwszeństwo zgłoszenia.

Aby przyśpieszyć działanie operacji we/wy, w module pracuje menedżer
bufora (Cache Manager). Wykorzystanie bufora kojarzy się zazwyczaj
z operacjami wejścia i wyjścia systemu plików, możliwe jest jednak
w stosunku do dowolnych komponentów sieciowych, sterowanych
menedżerem we/wy. Aktualnie moduł obsługuje trzy charakterystyczne
grupy sterowników:

Sterowniki urządzeń fizycznych - obsługę urządzeń fizycznych, typu
mysz lub klawiatura, realizują oddzielne sterowniki mogące
współpracować z menedżerem procesów we/wy. Takie rozwiązanie
pozwala, w razie potrzeby, wymieniać fizyczne komponenty systemu,
bez oddziaływania na inne urządzenia i sterowniki.

Sterowniki urządzeń systemu plików - implementacja tych sterowników
umożliwia wykorzystanie różnych systemów plików na tym samym
napędzie. Rozwiązanie, polegające na traktowaniu redirektora
sieciowego oraz serwera jako sterowników urządzeń systemu plików,
pozwala menedżerowi we/wy na dostęp do katalogów plików innych
serwerów, według tej samej zasady co do katalogów lokalnych.

Sterowniki urządzeń sieciowych - rozwiązania umożliwiające współpracę
z siecią

są integralną częścią systemu operacyjnego,

zaimplementowaną w

formie sterowników urządzeń sieciowych,

układu obsługi procesów wejścia i wyjścia. Obsługa różnych urządzeń
sieciowych jest zaimplementowana na różnym poziomie menedżera
procesów we/wy. Jak już wspomniano redirektor i

serwer są

zaimplementowane jako urządzenia systemu plików. Ulokowane są
w obszarze menedżera nazywanym interfejsem dostawczym (Provider
Interface). Na tym samym poziomie są ulokowane zarówno NetBIOS
jak i protokół Windows Sockets. Niższy poziom zajmują sterowniki
protokołów TCP/IP, NetBEUI, NWLink i DLC. Współpracę między
sterownikami protokołów komunikacyjnych, a sterownikami systemu
plików umożliwia mechanizm o

nazwie interfejs sterowników

komunikacyjnych (Transport Driver Interface). Sterowniki poziomu
komunikacyjnego są napisane zgodnie ze specyfikacją NDIS 3.0
(Network Device Interface Specification). Określa ona wspólne reguły,
umożliwiające wymianę informacji między adapterami fizycznymi,
a sterownikami protokołów komunikacyjnych. Ponadto pozwala
instalować na jednym komputerze wiele kart sieciowych i korzystać
z kilku protokołów komunikacyjnych.

Architektura systemu operacyjnego Windows NT

Uwaga

Windows 3.51 współpracował z trzema systemami plików: FAT (File Allocation

Table), NTFS (New Technology File System) oraz HPFS (High Performance File

System). W wersji 4.0 ograniczono możliwość współpracy do dwóch pierwszych.

Komponenty trybu użytkownika

Elementy składające się na warstwę trybu użytkownika można podzielić
na dwie kategorie. Pierwsza zawiera składniki, które są związane
z

systemem ochrony, druga grupuje podsystemy środowiskowe,

niezbędne do uruchomienia aplikacji działających na platformach
różnych systemów operacyjnych. W dalszej części rozdziału zostaną
omówione komponenty związane z ochroną systemu z uwzględnieniem
współdziałania z

kontrolerem wskaźników bezpieczeństwa. Teraz

skupimy się na podsystemach środowiskowych:

Podsystemy środowiskowe

Windows NT umożliwia uruchamianie aplikacji napisanych dla MS-DOS,
OS/2, Windows 3.x oraz aplikacji 32 bitowych napisanych dla Windows
NT. Taką elastyczność zapewniają różne podsystemy, zaprojektowane
w celu obsługi działania programów nie dedykowanych specjalnie dla
NT. Podczas uruchamiania aplikacji, układy te emulują działanie
odpowiedniego systemu operacyjnego.

Podsystemy środowiskowe mogą współdziałać z

komponentami

Windows NT Executive. Dostosowują usługi do specyficznych wymagań
środowiska stawianych przez programy niededykowane dla NT. Zaletą
stosowania różnych podsystemów jest izolowanie komponentów
wykonawczych od wpływu błędów generowanych przez programy,

Uwaga

Windows 3.51 zawiera ważne odstępstwo od tej reguły. Podsystemy Win32
sterują myszą, klawiaturą oraz wyjściem monitora łącznie dla wszystkich
podsystemów. Awaria Win32 rzutuje na pracę innych podsystemów zatrzyma-
niem pracy myszy, klawiatury i ekranu.

Wśród modułów omawianej grupy znajdują się wirtualne maszyny DOS
(VDS - Virtual Dos Machines) oraz kilka innych podsystemów. Z wyjąt-
kiem Win32 są opcjonalne, co oznacza, że ładują się w chwili, gdy są
potrzebne do obsługi aplikacji klienta. Oto lista podsystemów dostępnych
w Windows NT:

podsystem OS/2

Część I Przegląd systemu ochrony Microsoft Windows NT

podsystem POSIX

podsystem Win32

wirtualna maszyna MS-DOS

wirtualna maszyna Win16

Podsystem OS/2

Układ umożliwia uruchomienie aplikacji zbudowanej specjalnie dla OS/2
jedynie na platformie Intelx86. Komputery RISC nie współpracują
z podsystemem OS/2, ale aplikacje działające w trybie rzeczywistym
OS/2 mogą być uruchamiane w środowisku MS-DOS.

Podsystem POSIX

POSIX (Portable Operating System Interface for Computing Enviroments) jest
jedynie zbiorem standardów opracowanych przez IEEE (Institute of Elec-
trical and Electronic Engineers). Aktualnie tylko jeden ze standardów
otrzymał ostateczną postać i zaczyna być akceptowany przez klientów.
Ten standard to POSIX.1 lub inaczej IEEE standard 1003.1-1990. Definiuje
on interfejs programów użytkowych w języku C, działający pomiędzy
aplikacją a systemem operacyjnym. Z tego powodu aplikacje napisane
według standardów POSIX muszą zdawać się na działanie pod kontrolą
innych systemów operacyjnych, w zakresie usług związanych między
innymi z ochroną i pracą w sieci.

Wymagania stawiane przez POSIX systemowi plików, dotyczą rozróż-
niania wielkich liter oraz możliwości stosowania długich nazw. NTFS jest
zgodny z tym standardem. Aplikacje kompatybilne z POSIX mogą być
uruchamiane przy zastosowaniu innego systemu plików, o ile nie wyma-
gają do niego dostępu,

Podsystem Win32

Ten moduł jest odpowiedzialny za uruchamianie aplikacji Win32. W NT
3.51 steruje wyjściem monitora jak również współpracą myszy
i klawiatury. Ponieważ podsystem steruje funkcjami wejścia/wyjścia
Windows NT, wszystkie inne podsystemy zmuszone są korzystać z jego
usług w zakresie współdziałania z użytkownikiem (por. rysunek 3.3).

Uwaga

Odnotujmy, że powyższe uwagi odnoszą się do Windows NT 3.51 a nie NT 4.0.
W nowej wersji dokonano zmian, dzięki którym Win32 przestał sterować
omawianymi funkcjami. Więcej na ten temat przeczytamy w następnym
fragmencie rozdziału.

Architektura systemu operacyjnego Windows NT

Rysunek 3.3

Składniki podsys-
temu Win32
w Windows 3.5x

Podsystem Win32 steruje operacjami wejścia/wyjścia, używając kom-
binacji różnych usług, które opisujemy w poniższym wykazie: Console
Services (Usługi konsoli) zapewniają działanie okna tekstowego oraz
funkcji wygaszania systemu i obsługi błędów krytycznych. Dostarcza
32 bitowym aplikacjom Windows specjalizowanych funkcji typu two-
rzenie i usuwanie obiektów.

Window Manager (Menedżer okien) jest usługą działającą w chronionym
trybie pracy. Odpowiada za tworzenie interfejsu ekranu Windows.
Program współpracuje z interfejsem urządzeń graficznych (GDI- Gra-
phics Device Intarface, zarządzając informacjami graficznymi przepły-
wające do (oraz od) aplikacji. Standardową funkcją modułu jest przy-
jęcie żądania aplikacji (na przykład utworzenie okna) i wysłanie jej do
GDI. Z drugiej strony, wszystkie informacje związane ze zmianą
ekranu, zainicjowane przez użytkownika (na przykład przesunięcie
okna), są przesyłane przez moduł do aplikacji.

Graphics Device Interface (GDI - Interfejs urządzeń graficznych) jest rów-
nież programem działającym w chronionym trybie pracy. Moduł od-
powiada za tworzenie graficznych obrazów, zarówno na ekranie, jak
i na drukarce. Dostarcza zbioru standardowych funkcji, umożliwiają-
cych współpracę aplikacji z konkretnymi urządzeniami graficznymi.
GDI zarządza informacjami, dotyczącymi cech obrazu, przepływają-
cymi od aplikacji do sterownika graficznego. Dzięki GDI aplikacja
współpracuje z urządzeniem wyświetlającym (ekranem lub drukarką)
bez jakiejkolwiek znajomości cech urządzenia. O module można my-

Część I Przegląd systemu ochrony Microsoft Windows NT

śleć jako o tłumaczu, przekładającym z języka aplikacji, na język zro-
zumiały przez sterowniki rządzeń.

Graphics Device Drivers (Sterowniki urządzeń graficznych) Moduł składa
się ze zbioru bibliotek DLL, zawierających funkcje umożliwiające do-
stęp GDI do fizycznych urządzeń wyjściowych, najczęściej monitora
i drukarki. Sterowniki otrzymują od GDI zrozumiałe dla nich instruk-
cje i zlecają urządzeniom określone przez nie zadania. Wykorzystanie
sterowników pozwala na oddzielną implementację bardzo specyficz-
nych cech urządzeń w niezależnych modułach, które są obsługiwane
przez wspólny zbiór instrukcji. Sterowniki niskiego poziomu bezpo-
średnio regulują pracę urządzeń, natomiast sterowniki wysokiego po-
ziomu wpierają GDI dzieląc zadania na mniejsze części, zrozumiałe
dla sterowników niskiego poziomu.

Jak już mówiliśmy, usługi działają jako chronione procesy trybu użyt-
kownika. Z tego powodu wszystkie pozostałe podsystemy są traktowane
przez Windows NT 3.51 jako klienci Win32. Aby zapewnić funkcjonalną
współpracę między użytkownikiem a aplikacją, wszystkie podsystemy
muszą dostosować wezwania Win32 API do wymagań podsystemu Win
32. Najważniejszy, z punktu widzenia bezpieczeństwa problem polega na
tym, że awaria podsystemu Win32 wpływa na działanie systemu opera-
cyjnego, gdyż uniemożliwia korzystanie z myszy, klawiatury i ekranu.

Podsystem Win32 jest również modułem odpowiedzialnym za działanie
i sterowanie wirtualnej maszyny DOS (VDM). Wirtualne maszyny DOS
przeznaczone są do uruchamiania 16 bitowych aplikacji kompatybilnych
z Windows lub MS-DOS.

Wirtualna maszyna MS-DOS

Windows NT umożliwia uruchamianie aplikacji kompatybilnych z MS-
DOS przez symulowanie komputera bazującego na procesorze Intel 486,
działającego w systemie operacyjnym MS-DOS. Jednocześnie można
utworzyć kilka wirtualnych maszyn MS-DOS na jednym komputerze
działającym pod kontrolą NT. Jeśli system pracuje na platformie Intel,
dostępny jest tryb pracy procesora o nazwie Virtual-86. Umożliwia on
bezpośrednią realizację większości instrukcji, a jedynie kilka poleceń
we/wy musi być emulowanych programowo. Na komputerach RISC nie
jest dostępny tryb Virtual-86, zatem wszystkie instrukcje procesora 486 są
na tej platformie emulowane programowo.

Aby umożliwić normalną pracę aplikacji kompatybilnych z MS-DOS,
należy zasymulować kilka charakterystycznych własności tego
środowiska:

Architektura systemu operacyjnego Windows NT

Zbiór instrukcji Intel x86 jest zapewniany przez moduł wykonywania
instrukcji (Instruction Execution Unit)

Usługi przerwań - normalne działanie programów napisanych dla DOS
zależne jest od przerwań realizowanych przez BIOS. Wirtualna ma-
szyna MS_DOS emuluje te usługi.

Usługi przerwania nr 21 - przerwanie 21 jest normalnie realizowane na
poziomie MS-DOS. VDM zapewnia jego emulację.

Sterowniki urządzeń wirtualnych mają za zadanie symulować zbiór ste-
rowników, dostępnych normalnie dla aplikacji działających
w systemie MS-DOS.

Odnotujmy, że na komputerach z procesorem Intel aplikacje tekstowe są
uruchamiane w oknie, natomiast graficzne korzystają z pełnego ekranu.
Na platformie RISC oba rodzaje programów są uruchamiane w graficz-
nym oknie sesji.

Wirtualna maszyna Win16

System operacyjny Windows NT wyposażony jest w jedną - wielowąt-
kową wirtualną maszynę DOS dla 16 bitowych aplikacji Windows (zwa-
ny czasem WOW - Windows on Win32). Każda z aplikacji Win16 uru-
chamiana poprzez mechanizm wirtualny działa na zasadzie wielozada-
niowości bez wywłaszczania. Oznacza to, że w tym samym czasie może
być realizowana tylko jedna aplikacja, a pozostałe zmuszone są do ocze-
kiwania. Tym niemniej procesy realizowane przez WOW podlegają me-
chanizmom wielozadaniowości z wywłaszczeniem w stosunku do pozo-
stałych procesów działających w systemie.

Komponenty ochrony trybu użytkownika

Warstwa trybu użytkownika w systemie operacyjnym Windows NT za-
wiera różne składniki, które wspólnie tworzą podsystem ochrony:

Log-on Processes (Procesy rejestracji) pracują w trybie użytkownika
i służą do weryfikacji użytkowników rejestrujących się w systemie.
Dotyczy to zarówno użytkowników logujących się lokalnie, jak i ze
stacji odległych.

Local Security Authority (Lokalne upoważnienie ochrony) wspólnie
z procesami rejestracyjnymi służy do weryfikacji upoważnień przy-
znanych kontu użytkownika. Status konta użytkownika musi zostać
sprawdzony, zanim użytkownik uzyska dostęp do systemu. Ośrodek
zabezpieczeń lokalnych jest najważniejszym elementem podsystemu
bezpieczeństwa, pracującym w trybie użytkownika. Odnotujmy, że
składniki trybu użytkownika współpracują z jedynym komponentem

Część I Przegląd systemu ochrony Microsoft Windows NT

systemu bezpieczeństwa pracującym w trybie jądra, a mianowicie
kontrolerem wskaźników ochrony. W części rozdziału analizującej
procesy rejestracji poświęcimy temu problemowi więcej uwagi. Oma-
wiany moduł jest odpowiedzialny za współdziałanie z procesami reje-
stracyjnymi i generowanie przepustki dostępu do systemu (SAT- sys-
tem Access Token). Inne zadania komponentu to realizacja strategii
nadzoru i

wytwarzanie komunikatów o

zdarzeniach związanych

z rejestracją dla kontrolera wskaźników bezpieczeństwa (SRM).

Security Account Manager (Menedżer zabezpieczeń kont) pracuje
w trybie użytkownika i odpowiada za obsługę baz danych, zawierają-
cych informacje o kontach użytkowników. Współpracuje z poprzed-
nim składnikiem, dostarczając niezbędnych, do weryfikacji użytkow-
nika, informacji.

Opisane elementy tworzą razem z programem Security Reference Moni-
tor podsystem pod nazwą Windows NT Security Subsystem. Nie jest to
układ środowiskowy, ponieważ zawiera składowe pracujące w różnych
trybach. Z tego powodu nazywany jest podsystemem zintegrowanym.
O działaniu tego podsystemu powiemy nieco więcej w dalszej części roz-
działu, teraz natomiast przejrzymy zmiany w architekturze Windows NT
wprowadzone w wersji 4.0.

Zmiany architektury wprowadzone w Windows NT 4.0

Architektura systemu operacyjnego Windows NT 4.0 oparta jest na tych
samych założeniach co w wersji poprzedniej. Aby jednak podnieść wy-
dajność systemu, bez ograniczania poziomu integralności, wprowadzono
do systemu kilka modyfikacji zarówno w części wykonawczej, jak
i w podsystemie Win32.

Jak już mówiliśmy, centralne moduły systemu operacyjnego pracują
w pierścieniu 0 w trybie jądra. Jest to poziom o najwyższych przywilejach
w systemie. Należą do niego elementy w decydującym stopniu odpowie-
dzialne za współpracę z fizycznymi urządzeniami komputera. Podsys-
temy trybu użytkownika wywołują komponenty pracujące w trybie jądra,
celem wykonania operacji, umożliwiającej dostęp do urządzeń na pozio-
mie sprzętowym. Takie rozwiązanie daje gwarancje, że aplikacje pracują-
ce w jednym z trybów użytkownika (pierścień 3) nie mogą spowodować
zawieszenia systemu wykonując próbę dostępu do urządzeń fizycznych.
Zabezpieczenie to wiąże się z obniżeniem wydajności systemu. Powodem
spadku wydajności są przełączenia i przejścia międzypierścieniowe.

Architektura systemu operacyjnego Windows NT

Rysunek 3.4

Architektura
systemu Windows
NT 4.0

Przełączenia mają miejsce, gdy aplikacja Windows wywołuje funkcje API
podsystemu Win32. Z przejściami międzypierścieniowymi mamy do
czynienia, gdy kod pierścienia 3 wywołuje kod pierścienia 0. Aby sko-
munikować się z odpowiednim podsystemem, aplikacja musi bowiem
korzystać z pośrednictwa mechanizmu lokalnego wywołania procedur
(Local Procedure Call). Ponieważ Win32 zawiera interfejs urządzeń gra-
ficznych (GDI), to między podsystemem Win32 a Windows NT Executive
występują liczne dodatkowe przejścia międzypierścieniowe. Wszystkie te
przejścia łącznie odbijają się na wydajności.

Zmiany w Windows NT Executive

W warstwie jądra Windows NT 4.0 umieszczono dodatkowy komponent
o nazwie Win32K Executive. Nie należy jej mylić z systemem Windows
NT Executive, której składnikiem jest Win32K. Nowy komponent przejął
najważniejsze funkcje podsystemu Win32 trybu użytkownika.

Jak pamiętamy, podsystem Win32 zawierał kilka różnych komponentów
zarządzających współdziałaniem z urządzeniami graficznymi (menedżer
okien, GDI oraz sterowniki urządzeń graficznych), w szczególności
z wyjściem na graficzny monitor i drukarkę. Ponieważ współpraca była

Część I Przegląd systemu ochrony Microsoft Windows NT

inicjowana w trybie użytkownika (pierścień 3), przejścia międzypierście-
niowe miały miejsce przy realizacji wywołań Windows NT Executive
(pierścień 0). Win32K Executive jest w istocie, umieszczonym w trybie
jądra, nowym miejscem dla wymienionych elementów podsystemu
Win32. Skutkiem takiej zmiany jest usprawnienie pracy systemu.

Rysunek 3.5

Zmodyfikowa-
ny system
Windows NT
Executive
w wersji 4.0

W nowym systemie aplikacje realizują wywołania funkcji Win32K
w trybie jądra, omijając pośrednictwo podsystemów Win32. Nie eliminuje
to zupełnie przejść międzypierścieniowych, ale znacznie redukuje ich
liczbę. Inny sposób poprawienia wydajności polega na tworzeniu kolejki
wywołań i przesyłaniu ich w formie pakietu. Zamiast osobnych przejść
dla każdego wywołania można jednorazowo wysłać całą grupę. Celem
tego rozwiązania było również usprawnienie działania systemu.

Komponenty Win32K Executive

Win32K Executive jest nowym komponentem trybu jądra, który zastępuje
usługi wejścia/wyjścia, realizowane w poprzedniej wersji przez podsys-
tem Win32. Zamiast wykonywania chronionych procesów w trybie użyt-
kownika, realizuje je w ramach trybu jądra i pierścienia 0 (por. rysunek
3.6). Efektem jest podniesienie wydajności poprzez umożliwienie bezpo-
średnich wywołań z Win32K Executive do mikrojądra i abstrakcyjnej
warstwy sprzętowej (HAL).

Architektura systemu operacyjnego Windows NT

Rysunek 3.6

Win 32K Executive.

Win32K Executive składa się z kilku różnych elementów, odpowiedzial-
nych za określone funkcje:

Window Manager (Menedżer okien) odpowiada za tworzenie interfejsu
ekranu Windows. Program współpracuje z interfejsem urządzeń gra-
ficznych (GDI - Graphics Device Intarface) zarządzając informacjami
graficznymi przepływającymi do (oraz od) aplikacji. Standardową
funkcją modułu jest przyjęcie żądania aplikacji (na przykład utworze-
nie okna) i wysłanie jej do GDI. Z drugiej strony, wszystkie informacje
związane ze zmianą ekranu, zainicjowane przez użytkownika (na
przykład przesunięcie okna), są przesyłane przez moduł do aplikacji.

Graphics Device Intarface (interfejs urządzeń graficznych) odpowiada
za tworzenie graficznych obrazów zarówno na ekranie, jak i na dru-
karce. Dostarcza zbioru standardowych funkcji umożliwiających
współpracę aplikacji z konkretnymi urządzeniami graficznymi. GDI,
zarządza informacjami dotyczącymi cech obrazu przepływającymi od
aplikacji do sterownika graficznego. Dzięki GDI aplikacja współpracu-
je z urządzeniem wyświetlającym (ekranem lub drukarką) bez jakiej-
kolwiek znajomości cech urządzenia. O module można myśleć jako
o tłumaczu, przekładającym z języka aplikacji, na język zrozumiały
przez sterowniki urządzeń.

Graphics Device Drivers (sterowniki urządzeń graficznych) tworzą mo-
duł, będący zbiorem bibliotek DLL zawierających funkcje umożliwia-
jące dostęp GDI do fizycznych urządzeń wyjściowych, najczęściej mo-
nitora i drukarki. Sterowniki otrzymują od GDI zrozumiałe dla nich
instrukcje i zlecają urządzeniom określone przez nie zadania. Wyko-
rzystanie sterowników pozwala na oddzielną implementację bardzo
specyficznych cech urządzeń w niezależnych modułach, które są ob-

Część I Przegląd systemu ochrony Microsoft Windows NT

sługiwane przez wspólny zbiór instrukcji. Sterowniki niskiego pozio-
mu bezpośrednio regulują pracę urządzeń, natomiast sterowniki wy-
sokiego poziomu wpierają GDI, dzieląc zadania na mniejsze części,
zrozumiałe dla sterowników niskiego poziomu.

Znając już komponenty obu warstwy systemu operacyjnego, możemy
przyjrzeć się różnym, istotnym dla bezpieczeństwa procesom, które reali-
zują poszczególne elementy

System ochrony Windows NT

Moduły należące do warstw trybu jądra oraz trybu użytkownika wyko-
nują wiele wewnętrznych operacji systemowych. Rozpoczniemy od krót-
kiego przeglądu komponentów tworzących podsystem ochrony. Oto lista
składników wraz z opisem realizowanych przez nie funkcji:

Moduł procesów rejestracji służy do weryfikacji użytkowników rejestru-
jących się w systemie.

Ośrodek zabezpieczeń lokalnych{ XE „Ośrodek zabezpieczeń lokalnych” }
służy wspólnie z procesami rejestracyjnymi do weryfikacji upoważ-
nień przyznanych kontu użytkownika. Status konta użytkownika mu-
si zostać sprawdzony, zanim uzyska dostęp do systemu. Ośrodek za-
bezpieczeń lokalnych jest najważniejszym elementem podsystemu
bezpieczeństwa pracującym w trybie użytkownika. Moduł jest odpo-
wiedzialny za współdziałanie z

procesami rejestracyjnymi

i generowanie przepustki dostępu do systemu (SAT- System Access To-
ken). Inne zadania komponentu to realizacja strategii nadzoru
i wytwarzanie komunikatów o zdarzeniach związanych z rejestracją
dla kontrolera wskaźników bezpieczeństwa (SRM).

Security Account Manager (menedżer zabezpieczeń kont) jest obecnie
nazywany bazą danych usług katalogowych (directory services databa-
se). Moduł SAM odpowiada za obsługę baz danych zawierających in-
formacje o kontach użytkowników. W procesie rejestracji współpracu-
je z poprzednim składnikiem, dostarczając informacji niezbędnych do
weryfikacji użytkownika.

Kontroler wskaźników bezpieczeństwa - moduł służy do sterowania we-
wnętrzną ochroną systemu; zarządza dostępem, tworzeniem
i usuwaniem wszystkich obiektów w systemie. Swoje zadania wyko-
nuje dzięki liście kontroli dostępu (ACL- Access Control List), która jest
skojarzona z każdym obiektem. Każdy obiekt zawiera z kolei elemen-
ty o nazwie pozycje kontroli dostępu (ACE- Access Control Entries),
a każda z nich zawiera unikatowy identyfikator bezpieczeństwa użyt-
kownika lub grupy (SID- Security ID). W chwili obecnej identyfikator

Architektura systemu operacyjnego Windows NT

SID jest unikatową liczbą generowaną przez system operacyjny, która
jest przyporządkowana każdemu użytkownikowi (i

grupie)

w domenie.

Zanim obejrzymy z bliska proces rejestracji, musimy najpierw zdobyć
kilka informacji o identyfikatorach bezpieczeństwa oraz kontach użyt-
kownika. W chwili, gdy administrator systemu tworzy konto użytkowni-
ka, system kojarzy z nim unikatowy numer zwany identyfikatorem bez-
pieczeństwa (SID - Security IDentification number). Dopóki użytkownik
pozostaje aktywny w systemie, dopóty jest rozpoznawany przez ten
identyfikator. W razie usunięcia i ponownego utworzenia konta, system
przyznaje użytkownikowi zupełnie nowy identyfikator. Nie będzie mu
przydzielony żaden z atrybutów ochrony należny poprzedniemu kontu.
Każde uprawnienie, w które chcemy wyposażyć użytkownika, musi być
ponownie skojarzone z nowym kontem.

Proces rejestracji w systemie (Log-On Process)

Zakładamy, że czytelnikowi znany jest widok ekranu w czasie rejestracji
oraz przebieg procesu. Zaczynamy od wciśnięcia kombinacji klawiszy
CTRL+ALT+DEL

, która otwiera okno rozpoczynające rejestrację.

Wprowadzamy identyfikator swojego konta, hasło, wciskamy klawisz
OK

i jak za dotknięciem czarodziejskiej różdżki jesteśmy zalogowani

w systemie. Chociaż proces przebiega bardzo szybko, to zanim dobiegnie
końca, musi wydarzyć się wiele rzeczy.

Jedno ze zdarzeń polega na utworzeniu przepustki (SAT- Security Access
Token) obowiązującej na czas trwania sesji. Zawiera ona ciąg informacji
wykorzystywanych przy ubieganiu się o dostęp do zasobów systemu.
Znajdują się na niej między innymi identyfikatory użytkownika oraz
wszystkich grup, do których należy. Każdy program oraz proces
uruchomiony w kontekście konta użytkownika wyposażony jest w kopię
jego przepustki. Jeśli aplikacja żąda dostępu do obiektu, to przepustka
jest wykorzystywana do sprawdzenia, jakie uprawnienia ma do niego
użytkownik.

Każdy obiekt systemu operacyjnego zawiera listę uprawnień dostępu.
Lista jest porównywana z przepustką użytkownika żądającego dostępu
do zasobu. Jeżeli na liście znajduje się identyfikator użytkownika lub
grupy, do której należy, to uzyskuje dostęp do obiektu, zgodnie z pozio-
mem uprawnień określonym przez listę.

Proces rejestracji rozpoczyna się w chwili wciśnięcia kombinacji klawiszy
CTRL+ALT+DEL

[MF1]

, nazywanej czasem sekwencją skupienia nad bez-

pieczeństwem, której wynikiem jest wyświetlenie okna, zawierającego

Część I Przegląd systemu ochrony Microsoft Windows NT

żądanie podania nazwy konta i hasła. Celem takiego rozwiązania jest
zabezpieczenie przed możliwością przechwycenia danych identyfikacyj-
nych użytkownika przez program imitujący ekran rejestracyjny (takie
programy nazywamy koniami trojańskimi). Podana kombinacja klawiszy
generuje funkcję niskiego poziomu wywoływaną przez system operacyj-
ny, która nie może być skopiowana z poziomu programów. Przechwyce-
nie kombinacji CTRL+ALT+DEL i zmiana jej znaczenia jest jednak możli-
we na platformie DOS. Dlatego należy uważać na konie trojańskie działa-
jące w sesji DOS uruchamianej przez zrestartowanie konsoli z dyskietki.

Na żądanie systemu należy wprowadzić nazwę konta oraz hasło. Po-
twierdzenie danych identyfikacyjnych rozpoczyna proces, który musi się
zakończyć przyznaniem lub zakazaniem dostępu do systemu. Odebrane
przez proces rejestracji dane o użytkowniku są przekazywane do ośrodka
zabezpieczeń lokalnych, który wywołuje pakiet weryfikacyjny (authentifi-
cation package).

Oryginalny pakiet może być zastąpiony innym. Umożliwia to producen-
tom pisanie własnych pakietów identyfikacyjnych, których zadaniem jest
umożliwienie jednoczesnego dostępu do kilku systemów lub wykorzy-
stanie do potwierdzania tożsamości różnego rodzaju urządzeń fizycz-
nych. Przykładowo: czytników kart magnetycznych, głosu a nawet klu-
czy mechanicznych.

Pakiet identyfikacyjny sprawdza nazwę konta i hasło porównując je
z bazą danych kont użytkowników. Jeśli weryfikacja przebiegnie ko-
rzystnie, to menedżer ochrony kont (SAM) zwraca identyfikatory bezpie-
czeństwa (SID) użytkownika oraz wszystkich grup, których jest człon-
kiem. Pakiet identyfikacyjny tworzy sesję rejestracyjną, która wspólnie
z identyfikatorami jest przesyłana z powrotem do ośrodka zabezpieczeń
lokalnych.

W tym momencie moduł rozpoczyna tworzenie przepustki. Oprócz iden-
tyfikatora użytkownika i wszystkich grup, których jest członkiem prze-
pustka zawiera informację o uprawnieniach przynależnych do każdego
ID.

W kolejnym etapie przepustka jest zwracana procesowi rejestracji. Tu
wskutek skojarzenia przepustki z procesami tworzonym dla użytkowni-
ka przez podsystem Win32 powstaje zakres upoważnień użytkownika.
Od tego momentu podsystem Win32 uruchamia interaktywną sesję użyt-
kownika.

Jeżeli pakiet identyfikacyjny nie potwierdzi konta na lokalnej bazie da-
nych, to odpowiednia informacja zwracana jest pakietowi alternatywne-
mu (o ile istnieje w sieci). W razie niepowodzenia weryfikacji system
zwraca informację, że błędnie wprowadzono nazwę konta lub hasło.

Architektura systemu operacyjnego Windows NT

W takim przypadku użytkownik może podjąć ponowną próbę rejestracji
w systemie.

Uprawnienia użytkownika

Zazwyczaj różnym użytkownikom systemu przyznane są pewne ograni-
czone uprawnienia administracyjne. Prawo do wygaszania komputera
lub do archiwizacji plików są przykładami uprawnień użytkownika.
Różnica między prawami użytkownika a uprawnieniami dostępu tkwi
w sposobie ich przyznawania. Prawa dostępu są określane w wyniku
porównania identyfikatorów na przepustce użytkownika z zawartością
listy kontroli dostępu konkretnego obiektu. Prawa użytkownika dotyczą
aktywności, która nie jest związana ze specyficznym obiektem.

Zakres upoważnień użytkownika, pojęcie personifikacji

Jak już wcześniej wzmiankowano, zakres uprawnień konta użytkownika
jest kombinacją procesów wykonywanych przez Win32 oraz przepustki
użytkownika. Zazwyczaj zakres uprawnień konta dotyczy programów
uruchamianych przez użytkownika. Mówimy, że programy są urucha-
miane w kontekście uprawnień użytkownika. Zasada polega na ograni-
czeniu możliwości aplikacji do zakresu uprawnień posiadanych przez
osobę, która ją uruchamia.

W systemie operacyjnym Windows NT można mówić o dwóch rodzajach
zakresów upoważnień. Pierwszy, zwany prostym, dotyczy procesów, dla
których konteksty bezpieczeństwa zostały określone w momencie reje-
stracji. Drugi, zwany zakresem upoważnień serwera, dotyczy procesów
implementowanych przez chroniony serwer.

Próba wywołania usług obiektów chronionego podsystemu powoduje
sprawdzenie, czy zakres upoważnień zawiera wystarczające uprawnie-
nia. Czasami, wywoływane przez użytkownika, procesy serwera wyma-
gają dostępu do obiektów, do których nie mają uprawnień. Przejmują
wtedy atrybuty bezpieczeństwa klienta w procesie nazywanym personi-
fikacją. Umożliwia to dostęp do niezbędnych obiektów w kontekście
uprawnień użytkownika.

Obiekty, Typy obiektów

Jak już mówiliśmy, wszystkie obiekty reprezentują pewne procesy, użyt-
kowników lub zasoby zawarte w systemie. Każdy z nazwanych obiektów
(jak również niektóre nienazwane) zawiera deskryptor bezpieczeństwa.
Deskryptor składa się z różnych informacyjnych parametrów, opisują-

Część I Przegląd systemu ochrony Microsoft Windows NT

cych upoważnienia dostępu do obiektu. Informacje zawarte
w deskryptorze obejmują:

Identyfikator ochronny właściciela (owner security ID) określający
użytkownika (lub grupę), który jest właścicielem obiektu.

Identyfikator ochronny grupy jest elementem używanym jedynie
przez podsystem POSIX, pomijanym przez pozostałe podsystemy
Windows NT.

Lista kontroli dostępu (ACL{ XE „Lista kontroli dostępu (ACL)” }- Access
Control List) jest spisem użytkowników i grup mających uprawnienia
do obiektu. Zawiera również spis użytkowników i grup, którzy mają
indywidualnie zabroniony dostęp do obiektu.

Lista kontroli dostępu do systemu jest pozycją sterującą komunikata-
mi układu monitorującego; określa rodzaj wiadomości generowanych
przez system.

Obiekty można podzielić na proste (non-container) i złożone (container).
Obiekty złożone zawierają inne obiekty, które dziedziczą atrybuty bez-
pieczeństwa układów nadrzędnych. Atrybuty bezpieczeństwa, zależne są
od rodzaju obiektów, których dotyczą. Przykładowo: atrybuty bezpie-
czeństwa plików są różne od atrybutów kolejek drukarki.

Jak działa lista kontroli dostępu

Lista kontroli dostępu do obiektu zawiera informacje opisujące upraw-
nienia dostępu oraz zasady monitoringu przyznane użytkownikowi (lub
grupie) do konkretnego obiektu. Wiadomości zapisane są w odpowied-
nich pozycjach kontroli dostępu (ACEs-Access Control Entries). Lista może
zawierać trzy rodzaje pozycji. Pierwsze dwie są nazywane dyskrecjonal-
nymi, gdyż niosą informacje dotyczącą uprawnień dostępu (AccessAllo-
wed) lub ich braku (AccessDenied). Analiza dostępności do obiektu zaczy-
na się zawsze od przeglądu pozycji zabraniających dostępu. Trzeci typ
obejmuje pozycje systemu nadzoru (SystemAudit), decydujące o rodzaju
komunikatów generowanych system monitorujący, które zostaną zapisa-
ne w dzienniku zdarzeń systemu bezpieczeństwa.

W chwili, gdy użytkownik próbuje uzyskać dostęp do obiektu, kontroler
wskaźników bezpieczeństwa sprawdza numer identyfikatora na jego
przepustce, porównując go z pozycjami na liście kontroli dostępu. Jeśli
kontroler znajdzie pozycję zawierającą identyfikator, to przystępuje do
sprawdzania jej rodzaju. Gdy pozycja dyskrecjonalna zawiera informację
o zabronionym dostępie (AccessDenided), dostęp użytkownika do obiektu
jest niemożliwy i dalsza kontrola jest wstrzymana. Jeśli natomiast użyt-

Architektura systemu operacyjnego Windows NT

kownik ma prawo dostępu (AccessAllowed), kolejne procesy analizują tak
zwaną maskę dostępu użytkownika (Access Mask).

Wykorzystanie maski dostępu użytkownika

Każda pozycja uprawnionego dostępu (AccessAllowed) zawiera zbiór
uprawnień. Są one właściwe każdemu typowi obiektu i są wspólnie na-
zywane specyficzną maską dostępu pozycji kontroli (ACE’s specific access
mask). Określonych jest szesnaście poziomów dostępu, które mogą być
przyznane do każdego obiektu. Maski dostępu, które można skojarzyć
z każdym obiektem noszą nazwę standardowych masek dostępu (standard
access masks). Tworzą one zbiór uprawnień, które są wykorzystywane
łącznie ze specyficznymi maskami dostępu. Poniższa lista ilustruje maski
dostępu wykorzystywane przez Windows NT 4.0:

SYNCHRONIZE

służy do synchronizacji dostępu, uprawnia proces do

oczekiwania aż obiekt umożliwi wprowadzenie sygnalizowanego sta-
nu.

WRITE_OWNER{ XE „WRITE_OWNER” \t „Patrz Maski dostępu użytkow-
nika” }

uprawnia do przyznawania możliwości określania właściciela.

WRITE_DAC

uprawnia do przyznawania lub zabraniania modyfikacji

dyskrecjonalnych pozycji listy kontroli dostępu.

READ_CONTROL

uprawnia do przyznawania lub zabraniania prawa

odczytu deskryptora bezpieczeństwa i właściciela obiektu.

DELETE

uprawnia do przyznawania, odbierania lub usuwania prawa

dostępu.

Oprócz specyficznych i standardowych masek dostępu istnieje jeszcze
typ określany ogólnymi maskami dostępu (generic access mask). Ten rodzaj
masek określa zasięg uprawnień „natury ogólnej”. Są to:

GENERIC_READ

GENERIC_EXECUTE

Ogólne maski dostępu mogą być odwzorowane na specyficzny zbiór
uprawnień dostępu (lub specyficzną maskę dostępu) przez aplikację
tworzącą obiekt. Na przykład: GENERIC_EXECUTE może być
odwzorowana przez aplikację definiującą obiekt na jedną ze
specyficznych masek obiektu o nazwie FILE_RUN. Zazwyczaj wszystkie
ogólne typy masek są odwzorowywane na inne należące do typu stan-
dardowego lub specyficznego.

Co się dzieje jeśli użytkownik próbuje uzyskać dostęp do obiektu? Otóż
tworzona jest jeszcze jedna maska o nazwie maska pożądanego dostępu
(desired access mask). Zawiera ona listę uprawnień do wybranego obiektu,

Część I Przegląd systemu ochrony Microsoft Windows NT

potrzebnych użytkownikowi (lub procesowi działającemu w kontekście
uprawnień użytkownika).

Oto algorytm realizowany przez Windows NT celem weryfikacji upraw-
nień dostępu do zasobów przysługujących użytkownikowi lub aplikacji
działającej w kontekście jego uprawnień:

1. Przepustka użytkownika (SAT- Security Access Token) (lub aplikacji

działającej w kontekście jego uprawnień) jest porównywana ze zbio-
rem identyfikatorów wszystkich pozycji (ACE) listy kontroli dostępu
(ACL). Jeżeli żaden identyfikator z

przepustki nie zgadza się

z identyfikatorami pozycji dostępu, pozycja jest pomijana.

2. Wszystkie pozycje zabraniające dostępu są analizowane w pierwszej

kolejności. Jeśli dostęp do obiektu jest zabroniony, system sprawdza
czy maska pożądanego dostępu zawiera żądanie ReadControl lub (i)
WRITE_DAC. Jeśli tak, system sprawdza czy użytkownik jest właści-
cielem obiektu. Jeśli użytkownik jest właścicielem, to otrzymuje do-
stęp do obiektu, w przeciwnym razie dostęp do obiektu jest zabronio-
ny.

3. Jeśli dostęp do obiektu jest wykluczony zabraniającą dostępu pozycją

kontroli dostępu (AccessDenided ACE), dalsza analiza jest wstrzymana,
nawet jeśli inne uprawnienia znajdują się zarówno na następnych po-
zycjach ACE jak i na masce pożądanego dostępu. Dostęp użytkownika
do obiektu jest po prostu wykluczony.

4. Analiza jednej pozycji listy kontroli dostępu trwa do czasu znalezienia

jednej z wartości: dostęp uprawniony (AccessAllowed), lub dostęp za-
broniony (AccessDenided). Jeśli jedna z pozycji kontroli (ACE) zawiera
uprawnienie dostępu, to lista uprawnień maski pożądanego dostępu
jest porównywana ze spisem uprawnień pozycji kontroli (ACE). Jeżeli
lista uprawnień maski pożądanego dostępu zawiera żądania, wykra-
czające poza uprawnienia zawarte w spisie pozycji kontroli (ACE),
system analizuje w ten sam sposób kolejne pozycje kontroli (ACE) li-
sty kontroli dostępu (ACL). Użytkownik otrzymuje dostęp do obiektu,
jeśli wszystkie pozycje maski pożądanego dostępu występują na jed-
nej lub kilku pozycjach kontroli dostępu (ACE).

5. Dostęp do obiektu jest bezwarunkowo wykluczony, jeśli maska pożą-

danego dostępu zawiera choćby jedno żądanie nie występujące wśród
uprawnień zawartych na liście kontroli dostępu (ACL).

Znaczenie rejestrów Windows NT

Ważną rolę w systemie ochrony systemu operacyjnego spełniają rejestry.
Rejestry Windows NT (i Windows 95) zawierające wszystkie informacje

Architektura systemu operacyjnego Windows NT

konfiguracyjne, zastąpiły liczne zbiory inicjujące (*.ini), które występowa-
ły w Windows 3.x. Rejestry są złożoną strukturą, składającą się z wielu
pozycji, zawierających różne informacje niezbędne do właściwej konfigu-
racji i działania systemu. Każda pozycja może również zawierać pozycję
niższego rzędu, które z kolei znów zawierają dane lub pozycje rzędu
niższego.

Wszystkie pozycje rejestru są zorganizowane w układzie o strukturze
drzewa z pięcioma gałęziami głównymi. Każda gałąź ma własną, charak-
terystyczną strukturę. Jaka jest rola rejestrów w systemie ochrony?
Wszystkie informacje związane z bezpieczeństwem lokalnego komputera
są zawarte w jednej z gałęzi rejestrów. Jeśli serwer pełni rolę kontrolera
domeny, to wszystkie dane istotne dla bezpieczeństwa całej domeny są
również umieszczane w strukturze rejestrów. W szczególności cała baza
danych usług katalogowych (wcześniej baza danych SAM) dla domeny
zawiera się w rejestrach głównego lub zapasowych kontrolerów domeny.

Gałąź rejestrów o nazwie

HKEY_LOCAL_MACHINE

zawiera bazę danych

usług katalogowych oraz inne informacje związane z bezpieczeństwem
systemu. Te specyficzne pozycje oraz podstruktury są nazywane rojami
(hives), ponieważ reprezentują dyskretny zbiór powiązanych pozycji
i struktur. W przeciwieństwie do innych pozycji nie są tworzone dyna-
micznie, ale są stałą częścią systemu operacyjnego. Każdy rój jest związa-
ny z jednym (lub więcej ) zbiorem standardowych plików, w których
przechowywane są różne istotne informacje.

HKEY_LOCAL_MACHINE

zawiera różnorodne pozycje przechowujące

informacje związane z bezpieczeństwem, do najważniejszych należą:

HKEY_LOCAL_MACHINE\SAM

pozycja zawiera bazę danych usług kata-

logowych (dawniej

SAM

) dla kont użytkowników i grup. Jeśli serwer jest

kontrolerem domeny, to tutaj mieści się baza danych usług katalogowych
dla całej domeny. Standardowe pliki stowarzyszone z tą pozycją to Sam,
Sam.log oraz Sam.sav.

HKEY_LOCAL_MACHINE\Security

pozycja jest używana przez podsystem

ochrony Windows NT i zawiera informacje o regułach lokalnej strategii
ochrony. Standardowe zbiory skojarzone z pozycją to Security, Securi-
ty.log oraz Security.sav.

Struktura

HKEY_LOCAL_MACHINE\Sam

zawiera informacje systemu

ochrony o użytkownikach i grupach działających na maszynie lokalnej
lub w domenie. Jeżeli komputer jest kontrolerem domeny, pozycja jest
automatycznie odwzorowana i skopiowana na pozycję

HKEY_LOCAL_

MACHINE\security\SAM

Część I Przegląd systemu ochrony Microsoft Windows NT

Ostrzeżenie

Nie wolno zmieniać pozycji HKEY_LOCAL_MACHINE\SAM, ani żadnej
struktury podrzędnej przy pomocy programu narzędziowego do edycji rejestrów
(Windows NT registry editor). Wszystkie informacje tej pozycji zapisane są
w formacie binarnym i nie mogą być edytowane „ręcznie”. Wszystkie niezbędne
zmiany dotyczące ochrony użytkowników, grup, uprawnień NTFS powinny być
wykonywane odpowiednimi narzędziami systemowymi takimi jak User
Manager for Domains.

Ważna jest systematyczna archiwizacja rejestrów, zwłaszcza jeśli baza
danych usług katalogowych podlega częstym zmianom. Kopię zapasową
najłatwiej wykonać przy użyciu systemowego programu archiwizującego
(NT Backup). Dobrze mięć również więcej niż jeden kontroler domeny, co
zapewnia ciągłą dostępność bazy danych usług katalogowych.

W innych rozdziałach...

Skończywszy naukę o architekturze systemu możemy przejść do studio-
wania metod tworzenia domen i określania relacji upoważnienia.

Rozdział 4 - Pojęcie domen Windows NT- wprowadza w szczegóły procesu
tworzenia i administrowania domeną. Poznamy wiele metod ułatwiających
zadania administracyjne.

Rozdział 5 - Rola relacji upoważnienia między domenami w systemie ochrony - uczy
dlaczego, kiedy i jak tworzyć typowe modele domen wykorzystując różne re-
lacje upoważnienia.

Rozdział 6 - Ochrona kont użytkownika w systemie Windows NT- skupia się na
szczegółach tworzenia i konserwacji kont użytkowników i grup. Omówimy
typy predefiniowanych kont Windows NT oraz sytuacje, w których należy
z nich korzystać.