Model zabezpieczeń systemu Windows dla deweloperów sterowników
Model zabezpieczeń systemu Windows jest oparty na zabezpieczanych obiektach. Każdy składnik systemu operacyjnego musi zapewnić bezpieczeństwo obiektów, dla których jest odpowiedzialny. W związku z tym kierowcy muszą chronić bezpieczeństwo swoich urządzeń i obiektów urządzeń.
W tym temacie przedstawiono podsumowanie sposobu zastosowania modelu zabezpieczeń systemu Windows do sterowników trybu jądra.
Model zabezpieczeń systemu Windows
Model zabezpieczeń systemu Windows opiera się głównie na prawach poszczególnych obiektów z niewielką liczbą uprawnień dla całego systemu. Obiekty, które można zabezpieczyć, obejmują , ale nie są ograniczone do procesów, wątków, zdarzeń i innych obiektów synchronizacji, a także plików, katalogów i urządzeń.
Dla każdego typu obiektu ogólne prawa odczytu, zapisu i wykonywania są mapowane na szczegółowe prawa specyficzne dla danego obiektu. Na przykład w przypadku plików i katalogów możliwe prawa obejmują prawo do odczytu lub zapisu pliku lub katalogu, prawo do odczytu lub zapisu rozszerzonych atrybutów plików, prawo do przechodzenia do katalogu oraz prawo do zapisu deskryptora zabezpieczeń obiektu.
Model zabezpieczeń obejmuje następujące pojęcia:
- Identyfikatory zabezpieczeń (SID)
- Tokeny dostępu
- Deskryptory zabezpieczeń
- Listy kontroli dostępu (ACL)
- Uprawnienia
Identyfikatory zabezpieczeń (SID)
Identyfikator zabezpieczeń (SID, nazywany również podmiotem zabezpieczeń) identyfikuje użytkownika, grupę lub sesję logowania. Każdy użytkownik ma unikatowy identyfikator SID, który jest pobierany przez system operacyjny podczas logowania.
Identyfikatory SID są wystawiane przez urząd, taki jak system operacyjny lub serwer domeny. Niektóre identyfikatory SID są dobrze znane i mają także nazwy. Na przykład identyfikator SID S-1-1-0 identyfikuje wszystkich (lub świat).
Tokeny dostępu
Każdy proces ma token dostępu. Token dostępu opisuje pełny kontekst zabezpieczeń procesu. Zawiera identyfikator SID użytkownika, identyfikator SID grup, do których należy użytkownik, oraz identyfikator SID sesji logowania, a także listę uprawnień dla całego systemu przyznanych użytkownikowi.
Domyślnie system używa podstawowego tokenu dostępu do procesu za każdym razem, gdy wątek procesu wchodzi w interakcję z zabezpieczanym obiektem. Jednak wątek może podszywać się pod konto klienta. Gdy wątek impersonuje, ma token impersonacji oprócz własnego tokenu podstawowego. Token personifikacji opisuje kontekst zabezpieczeń konta użytkownika, podszywającego się pod wątek. Podszywanie się jest szczególnie powszechne w obsłudze zdalnych wywołań procedur (RPC).
Token dostępu opisujący ograniczony kontekst zabezpieczeń wątku lub procesu jest nazywany tokenem ograniczonym. Identyfikatory SID w tokenie z ograniczeniami można ustawić tylko w celu odmowy dostępu, a nie zezwalania na dostęp do zabezpieczanych obiektów. Ponadto token może opisywać ograniczony zestaw uprawnień dla całego systemu. Identyfikator SID użytkownika i tożsamość pozostają takie same, ale prawa dostępu użytkownika są ograniczone, podczas gdy proces używa tokenu z ograniczeniami. Funkcja CreateRestrictedToken tworzy token ograniczony.
Deskryptory zabezpieczeń
Każdy nazwany obiekt systemu Windows ma deskryptor zabezpieczeń; niektóre nienazwane obiekty również. Deskryptor zabezpieczeń opisuje identyfikatory SID właściciela i grupy dla obiektu wraz z jego listami kontroli dostępu (ACL).
Deskryptor zabezpieczeń obiektu jest zwykle tworzony przez funkcję tworzącą obiekt. Gdy sterownik wywołuje rutynę IoCreateDevice lub IoCreateDeviceSecure w celu utworzenia obiektu urządzenia, system stosuje deskryptor zabezpieczeń do tego obiektu i ustawia odpowiednie listy ACL. Dla większości urządzeń listy ACL są określone w pliku informacji urządzenia (INF).
Aby uzyskać więcej informacji na temat deskryptorów zabezpieczeń, zapoznaj się z dokumentacją sterownika jądra.
Listy kontroli dostępu
Listy kontroli dostępu (ACL) umożliwiają szczegółową kontrolę nad dostępem do obiektów. Lista kontroli dostępu (ACL) jest częścią deskryptora zabezpieczeń dla każdego obiektu.
Każda ACL zawiera zero lub więcej wpisów kontroli dostępu (ACE). Każda ACE z kolei zawiera pojedynczy identyfikator SID, który identyfikuje użytkownika, grupę lub komputer oraz listę praw, które są odmówione lub dozwolone temu identyfikatorowi SID.
Listy ACL dla obiektów urządzeń
ACL obiektu urządzenia można określić na jeden z trzech sposobów:
- Ustawione w domyślnym deskryptorze zabezpieczeń dla swojego typu urządzenia.
- Utworzono programowo przez funkcję RtlCreateSecurityDescriptor i ustawioną przez funkcję RtlSetDaclSecurityDescriptor.
- Określony w języku SDDL (Security Descriptor Definition Language) w pliku INF urządzenia lub w wywołaniu procedury IoCreateDeviceSecure.
Wszyscy sterownicy powinni używać języka SDDL w pliku INF do określania list ACL dla obiektów urządzeń.
SDDL to rozszerzalny język opisu, który umożliwia składnikom tworzenie list ACL w formacie ciągu. SDDL jest używany zarówno przez kod w trybie użytkownika, jak i w trybie jądra. Na poniższej ilustracji przedstawiono format ciągów SDDL dla obiektów urządzeń.
Wartość programu Access określa typ dozwolonego dostępu. Wartość identyfikatora SID określa identyfikator zabezpieczeń, który określa, do kogo ma zastosowanie wartość programu Access (na przykład użytkownik lub grupa).
Na przykład następujący ciąg SDDL zezwala systemowi (SY) na dostęp do wszystkich elementów i umożliwia wszystkim innym (WD) dostęp tylko do odczytu:
“D:P(A;;GA;;;SY)(A;;GR;;;WD)”
Plik nagłówka wdmsec.h zawiera również zestaw wstępnie zdefiniowanych ciągów SDDL, które są odpowiednie dla obiektów urządzeń. Na przykład plik nagłówkowy definiuje SDDL_DEVOBJ_SYS_ALL_ADM_RWX_WORLD_RWX_RES_RWX w następujący sposób:
"D:P(A;;GA;;;SY)(A;;GRGWGX;;;BA)(A;;GRGWGX;;;WD)(A;;GRGWGX;;;RC)"
Pierwszy segment tego ciągu umożliwia pełne sterowanie urządzeniem przez jądro i system operacyjny (SY). Drugi segment umożliwia wszystkim osobom w wbudowanej grupie Administratorzy (BA) dostęp do całego urządzenia, ale nie zmienia listy ACL. Trzeci segment umożliwia wszystkim (WD) odczyt lub zapis na urządzeniu, a czwarty segment przyznaje te same prawa niezaufanemu kodowi (RC). Sterowniki mogą używać wstępnie zdefiniowanych ciągów w postaci lub jako modeli dla ciągów specyficznych dla obiektu urządzenia.
Wszystkie obiekty urządzeń w stosie powinny mieć te same listy ACL. Zmiana list ACL na pojedynczym obiekcie urządzenia w stosie powoduje zmianę list ACL na całym stosie urządzeń.
Jednak dodanie nowego obiektu urządzenia do stosu nie powoduje zmiany list ACL albo tych z nowego obiektu urządzenia (jeśli ma listy ACL) lub obiektów istniejących urządzeń w stosie. Gdy sterownik tworzy nowy obiekt urządzenia i dołącza go na szczyt stosu, powinien skopiować listy ACL dla tego stosu do nowego obiektu urządzenia, kopiując pole DeviceObject.Characteristics z następnego, niższego sterownika.
Procedura IoCreateDeviceSecure obsługuje podzestaw ciągów SDDL, które używają wstępnie zdefiniowanych identyfikatorów SID, takich jak WD i SY. Interfejsy API trybu użytkownika i pliki INF obsługują pełną składnię SDDL.
Sprawdzanie zabezpieczeń przy użyciu list kontroli dostępu (ACL)
Gdy proces żąda dostępu do obiektu, kontrola zabezpieczeń porównuje listy kontroli dostępu (ACL) dla obiektu z identyfikatorami SID w tokenie dostępu wywołującego.
System porównuje ACEs ściśle od góry do dołu i zatrzymuje się na pierwszym odpowiednim dopasowaniu. W związku z tym podczas tworzenia listy ACL należy zawsze umieścić ACE odmowy powyżej odpowiednich ACE przyznania. W poniższych przykładach pokazano, jak przebiega porównywanie.
Przykład 1: porównanie listy ACL z tokenem dostępu
Przykład 1 pokazuje, jak system porównuje listę ACL z tokenem dostępu dla procesu wywołującego. Załóżmy, że obiekt wywołujący chce otworzyć plik zawierający listę ACL pokazaną w poniższej tabeli.
listy ACL przykładowego pliku
| Pozwolenie | SID | Dostęp |
|---|---|---|
| Pozwól | Rachunkowość | Pisanie, usuwanie |
| Pozwól | Sprzedaż | Dołączyć |
| Odrzuć | Prawny | Dołączanie, zapisywanie, usuwanie |
| Proszę pozwolić | Każdy | Przeczytaj |
Ta lista kontroli dostępu (ACL) ma cztery zasady ACL, które dotyczą bezpośrednio grup Księgowość, Sprzedaż, Dział Prawny i Wszyscy.
Następnie załóżmy, że token dostępu dla procesu żądania zawiera identyfikatory SID dla jednego użytkownika i trzech grup w następującej kolejności:
Użytkownik Jim (S-1-5-21...)
Księgowość grup (S-1-5-22...)
Group Legal (S-1-5-23...)
Grupuj wszystkich (S-1-1-0)
Podczas porównywania listy ACL pliku z tokenem dostępu system najpierw szuka ACE dla użytkownika Jim w liście ACL pliku. Żadna się nie pojawia, więc następnie szuka ACE dla grupy Księgowość. Jak pokazano w poprzedniej tabeli, ACE dla grupy Księgowość jest wyświetlana jako pierwszy wpis w liście ACL pliku, więc proces Jima ma prawo do zapisu lub usuwania pliku, a porównanie zatrzymuje się. Jeśli ACE dla grupy prawnej poprzedziłby ACE dla grupy księgowej w ACL, procesowi odmówiono by zapisu, dołączania i usuwania dostępu do pliku.
Przykład 2: porównanie listy ACL z tokenem o ograniczeniach
System porównuje listę ACL z tokenem ograniczonym w taki sam sposób, że porównuje je w tokenie, który nie jest ograniczony. Jednak identyfikator SID odmowy w tokenie z ograniczeniami może być zgodny tylko z odmową ACE na liście ACL.
Przykład 2 pokazuje, jak system porównuje listę kontroli dostępu (ACL) pliku z tokenem ograniczonym. Załóżmy, że plik ma tę samą listę ACL pokazaną w poprzedniej tabeli. W tym przykładzie proces ma jednak ograniczony token zawierający następujące identyfikatory SI:
Użytkownik Jim (S-1-5-21...) Zaprzeczać
Księgowość grup (S-1-5-22...) Zaprzeczać
Group Legal (S-1-5-23...) Odmowa
Grupuj wszystkich (S-1-1-0)
Lista ACL pliku nie wyświetla identyfikatora SID Jima, więc system przechodzi do identyfikatora SID grupy księgowości. Chociaż lista ACL pliku ma ACE dla grupy księgowości, ten ACE zezwala na dostęp; idąc w ślad za tym, nie odpowiada identyfikatorowi SID w ograniczonym tokenie procesu, który odmawia dostępu. W rezultacie system przechodzi do identyfikatora SID grupy prawnej. Lista ACL pliku zawiera ACE dla grupy prawnej, która odmawia dostępu, więc proces nie może zapisywać, dołączać ani usuwać pliku.
Uprawnienia
Uprawnieniem jest wykonanie przez użytkownika operacji związanej z systemem na komputerze lokalnym, takich jak ładowanie sterownika, zmienianie czasu lub zamykanie systemu.
Uprawnienia różnią się od praw dostępu, ponieważ mają zastosowanie do zadań i zasobów związanych z systemem, a nie obiektów, a ponieważ są przypisane do użytkownika lub grupy przez administratora systemu, a nie przez system operacyjny.
Token dostępu dla każdego procesu zawiera listę uprawnień przyznanych procesowi. Uprawnienia muszą być specjalnie włączone przed użyciem. Aby uzyskać więcej informacji na temat przywilejów, zobacz Przywileje w dokumentacji sterownika jądra.
Polecenia debugera związane z zabezpieczeniami
Rozszerzenie !ACL formatuje i wyświetla zawartość listy kontroli dostępu (ACL). Aby uzyskać więcej informacji, zobacz Określenie listy ACL obiektu i !acl.
Rozszerzenie !token wyświetla sformatowany widok obiektu tokenu zabezpieczającego. Aby uzyskać więcej informacji, zobacz !token.
Rozszerzenie !tokenfields wyświetla nazwy i przesunięcia pól w obiekcie tokenu dostępu (strukturze TOKEN). Aby uzyskać więcej informacji, zobacz !tokenfields.
Rozszerzenie !sid wyświetla identyfikator zabezpieczeń (SID) pod określonym adresem. Aby uzyskać więcej informacji, zobacz !sid.
Rozszerzenie !sd wyświetla deskryptor zabezpieczeń pod określonym adresem. Aby uzyskać więcej informacji, zobacz !sd.
Scenariusz modelu zabezpieczeń systemu Windows: tworzenie pliku
System używa konstrukcji zabezpieczeń opisanych w modelu zabezpieczeń systemu Windows za każdym razem, gdy proces tworzy dojście do pliku lub obiektu.
Na poniższym diagramie przedstawiono akcje związane z zabezpieczeniami, które są wyzwalane, gdy proces trybu użytkownika próbuje utworzyć plik.
Na poprzednim diagramie pokazano, jak system reaguje, gdy aplikacja trybu użytkownika wywołuje funkcję CreateFile. Poniższe uwagi odnoszą się do liczb okręgowych na rysunku:
- Aplikacja trybu użytkownika wywołuje funkcję CreateFile, przekazując prawidłową nazwę pliku Microsoft Win32.
- Tryb użytkownika Kernel32.dll przekazuje żądanie do Ntdll.dll, który konwertuje nazwę Win32 na nazwę pliku systemu Microsoft Windows NT.
- Ntdll.dll wywołuje funkcję NtCreateFile z nazwą pliku systemu Windows. W obrębie Ntoskrnl.exemenedżer wejścia/wyjścia obsługuje NtCreateFile.
- Menedżer wejścia/wyjścia ponownie pakuje żądanie w wywołanie Menedżera obiektów.
- Menedżer obiektów rozpoznaje łącza symboliczne i zapewnia, że użytkownik ma prawa przechodzenia dla ścieżki, w której zostanie utworzony plik. Aby uzyskać więcej informacji, zobacz kontrole zabezpieczeń w Menedżerze obiektów.
- Menedżer obiektów wywołuje składnik systemowy, który jest właścicielem bazowego typu obiektu skojarzonego z żądaniem. W przypadku żądania utworzenia pliku ten składnik jest menedżerem we/wy, który jest właścicielem obiektów urządzeń.
- Menedżer wejścia/wyjścia sprawdza deskryptor zabezpieczeń obiektu urządzenia w zestawieniu z tokenem dostępu dla procesu użytkownika, aby upewnić się, że użytkownik ma wymagany dostęp do urządzenia. Aby uzyskać więcej informacji, zobacz Sprawdzanie zabezpieczeń w Menedżerze We/Wy.
- Jeśli proces użytkownika ma wymagany dostęp, Menadżer We/Wy tworzy uchwyt i wysyła żądanie IRP_MJ_CREATE do sterownika dla urządzenia lub systemu plików.
- Sterownik wykonuje dodatkowe kontrole zabezpieczeń zgodnie z potrzebami. Jeśli na przykład żądanie określa obiekt w przestrzeni nazw urządzenia, sterownik musi upewnić się, że obiekt wywołujący ma wymagane prawa dostępu. Aby uzyskać więcej informacji, zobacz Sprawdzanie zabezpieczeń w sterowniku.
Kontrole zabezpieczeń w Menedżerze obiektów
Odpowiedzialność za sprawdzanie praw dostępu należy do składnika najwyższego poziomu, który może wykonywać takie kontrole. Jeśli Menedżer obiektów może zweryfikować prawa dostępu obiektu wywołującego, robi to. Jeśli nie, Menedżer obiektów przekazuje żądanie do składnika odpowiedzialnego za typ obiektu bazowego. Ten składnik z kolei weryfikuje dostęp, jeśli może; jeśli nie, przekazuje żądanie do jeszcze niższego składnika, takiego jak sterownik.
Menedżer obiektów sprawdza listy ACL dla prostych typów obiektów, takich jak zdarzenia i blokady mutex. W przypadku obiektów, które mają przestrzeń nazw, właściciel typu wykonuje kontrole zabezpieczeń. Na przykład Menedżer I/O jest uważany za administratora typu dla obiektów urządzeń i obiektów plików. Jeśli Menedżer obiektów znajdzie nazwę obiektu lub obiektu pliku urządzenia podczas analizowania nazwy, przekazuje nazwę menedżerowi we/wy, tak jak w scenariuszu tworzenia pliku przedstawionym powyżej. Menedżer I/O sprawdza prawa dostępu, jeśli może. Jeśli nazwa określa obiekt w przestrzeni nazw urządzenia, Menedżer we/wy przekazuje tę nazwę sterownikowi urządzenia (lub systemu plików), a sterownik ten jest odpowiedzialny za weryfikację żądanego dostępu.
Kontrole zabezpieczeń w Menedżerze I/O
Gdy menedżer we/wy tworzy uchwyt, sprawdza prawa obiektu względem tokenu dostępu procesu, a następnie przechowuje prawa przyznane użytkownikowi wraz z uchwytem. Po nadejściu kolejnych żądań we/wy Menedżer operacji We/Wy sprawdza prawa skojarzone z uchwytem, aby upewnić się, że proces ma prawo do wykonania żądanej operacji we/wy. Jeśli na przykład proces później zażąda operacji zapisu, Menedżer we/wy sprawdza prawa skojarzone z uchwytem, aby upewnić się, że wywołujący ma prawo zapisu do obiektu.
Jeśli uchwyt zostanie zduplikowany, prawa można usunąć z kopii, ale nie dodać do niej.
Gdy menedżer we/wy tworzy obiekt, konwertuje ogólne tryby dostępu Win32 na prawa specyficzne dla obiektu. Na przykład następujące prawa dotyczą plików i katalogów:
| Tryb dostępu Win32 | Prawa specyficzne dla obiektu |
|---|---|
| OGÓLNE_CZYTANIE | ReadData |
| GENERIC_WRITE (ogólne pisanie) | ZapiszDane |
| OGÓLNE_WYKONANIE | ReadAttributes |
| GENERIC_ALL | Wszystko |
Aby utworzyć plik, proces musi mieć prawa przechodzenia do katalogów nadrzędnych w ścieżce docelowej. Aby na przykład utworzyć \Device\CDROM0\Directory\File.txt, proces musi mieć prawo do przechodzenia przez \Device, \Device\CDROM0 i \Device\CDROM0\Directory. Menedżer we/wy sprawdza tylko prawa dostępu dla tych katalogów.
Menedżer we/wy sprawdza uprawnienia dostępu podczas analizowania nazwy pliku. Jeśli nazwa pliku jest łączem symbolicznym, menedżer we/wy rozpoznaje ją w pełnej ścieżce, a następnie sprawdza prawa przechodzenia, zaczynając od katalogu głównego. Załóżmy na przykład, że łącze symboliczne \DosDevices\D jest mapowane na nazwę urządzenia Windows NT \Device\CDROM0. Proces musi mieć prawa przechodzenia do katalogu \Device.
Aby uzyskać więcej informacji, zobacz Object Handles and Object Security.
Kontrole zabezpieczeń w sterowniku
Jądro systemu operacyjnego traktuje każdy sterownik, w efekcie, jako system plików z własną przestrzenią nazw. W związku z tym, gdy wywołujący próbuje utworzyć obiekt w przestrzeni nazw urządzenia, Menedżer we/wy sprawdza, czy proces ma prawa do przechodzenia przez katalogi w ścieżce.
W przypadku sterowników WDM Menedżer we/wy nie wykonuje kontroli zabezpieczeń względem przestrzeni nazw, chyba że obiekt urządzenia został utworzony z określeniem FILE_DEVICE_SECURE_OPEN. Jeśli FILE_DEVICE_SECURE_OPEN nie jest ustawiona, sterownik jest odpowiedzialny za zapewnienie bezpieczeństwa przestrzeni nazw. Aby uzyskać więcej informacji, zobacz Kontrolowanie dostępu do przestrzeni nazw urządzeń i zabezpieczanie obiektów urządzeń .
W przypadku sterowników WDF flaga FILE_DEVICE_SECURE_OPEN jest zawsze ustawiona, co oznacza, że następuje sprawdzenie deskryptora zabezpieczeń urządzenia przed zezwoleniem aplikacji na dostęp do nazw w przestrzeni nazw urządzenia. Aby uzyskać więcej informacji, zobacz Kontrolowanie dostępu do urządzeń w sterownikach KMDF.
Granice zabezpieczeń systemu Windows
Sterowniki komunikujące się ze sobą oraz z wywołującymi w trybie użytkownika o różnych poziomach uprawnień mogą być uważane za przekraczające granicę zaufania. Granica zaufania to dowolna ścieżka wykonywania kodu, która przechodzi z niższego procesu uprzywilejowanego do wyższego uprzywilejowanego procesu.
Im większa różnica w poziomach uprawnień, tym bardziej interesująca jest granica dla atakujących, którzy chcą przeprowadzać ataki, takie jak eskalacja uprawnień, na docelowy sterownik lub proces.
Częścią procesu tworzenia modelu zagrożeń jest zbadanie granic zabezpieczeń i wyszukanie nieprzewidzianych ścieżek. Aby uzyskać więcej informacji, zobacz Modelowanie zagrożeń dla sterowników.
Wszystkie dane, które przekraczają granicę zaufania, są niezaufane i muszą zostać zweryfikowane.
Na tym diagramie przedstawiono trzy sterowniki jądra i dwie aplikacje — jedną w kontenerze aplikacji i jedną aplikację, która działa z uprawnieniami administratora. Czerwone linie wskazują przykładowe granice zaufania.
Ponieważ kontener aplikacji może zapewnić dodatkowe ograniczenia i nie działa na poziomie administratora, ścieżka (1) jest wyższą ścieżką ryzyka dla ataku eskalacji, ponieważ granica zaufania znajduje się między kontenerem aplikacji (procesem o bardzo niskim poziomie uprawnień) i sterownikiem jądra.
Ścieżka (2) jest ścieżką o niższym ryzyku, ponieważ aplikacja działa z prawami administratora i wywołuje bezpośrednio sterownik jądra. Administrator jest już dość wysokim poziomem uprawnień w systemie, więc obszar ataku od administratora do jądra jest mniej interesującym celem dla atakujących, ale nadal istotną granicą zaufania.
Ścieżka (3) to przykład ścieżki wykonywania kodu, która przekracza wiele granic zaufania, które mogą zostać pominięte, jeśli model zagrożenia nie zostanie utworzony. W tym przykładzie istnieje granica zaufania między sterownikiem 1 i sterownikiem 3, ponieważ sterownik 1 pobiera dane wejściowe z aplikacji trybu użytkownika i przekazuje go bezpośrednio do sterownika 3.
Wszystkie dane wejściowe przychodzące do sterownika z trybu użytkownika są niezaufane i powinny być weryfikowane. Dane wejściowe pochodzące z innych sterowników mogą być również niezaufane w zależności od tego, czy poprzedni sterownik był tylko prostym przekazaniem naprzód (np. dane zostały odebrane przez sterownik 1 z aplikacji 1, sterownik 1 nie zrobił żadnej weryfikacji danych i właśnie przekazał je do sterownika 3). Pamiętaj, aby zidentyfikować wszystkie powierzchnie ataków i granice zaufania oraz zweryfikować wszystkie dane, które je przekraczają, tworząc kompletny model zagrożeń.
Zalecenia dotyczące modelu zabezpieczeń systemu Windows
- Ustaw silne domyślne listy kontroli dostępu w wywołaniach funkcji IoCreateDeviceSecure.
- Określ listy ACL w pliku INF dla każdego urządzenia. Te listy kontroli dostępu mogą w razie potrzeby poluzować sztywne domyślne listy ACL.
- Ustaw charakterystykę FILE_DEVICE_SECURE_OPEN, aby zastosować ustawienia zabezpieczeń obiektu urządzenia do przestrzeni nazw urządzeń.
- Nie należy definiować IOCTL, które umożliwiają FILE_ANY_ACCESS, chyba że taki dostęp nie może zostać wykorzystany złośliwie.
- Użyj procedury IoValidateDeviceIoControlAccess, aby zaostrzyć zabezpieczenia istniejących systemów IOCTLS, które umożliwiają FILE_ANY_ACCESS.
- Utwórz model zagrożeń, aby zbadać granice zabezpieczeń i wyszukać nieprzewidziane ścieżki. Aby uzyskać więcej informacji, zobacz Modelowanie zagrożeń dla sterowników.
- Aby uzyskać dodatkowe zalecenia dotyczące zabezpieczeń sterowników, zobacz
lista kontrolna dotycząca zabezpieczeń sterowników.