Stosowanie deskryptorów zabezpieczeń w obiekcie urządzenia

Większość sterowników korzysta z mechanizmów kontroli dostępu stosowanych przez menedżera we/wy na swoich obiektach urządzeń, aby chronić się przed niewłaściwym dostępem. Najprostszym podejściem dla większości sterowników jest zastosowanie jawnego deskryptora zabezpieczeń podczas instalowania sterownika. W pliku INF takie deskryptory zabezpieczeń są opisane przez wpis "Zabezpieczenia" w sekcji AddReg. Aby uzyskać więcej informacji na temat kompletnego języka używanego do opisywania deskryptorów zabezpieczeń, zobacz Język definicji deskryptora zabezpieczeń w dokumentacji zestawu Microsoft Windows SDK.

Podstawowy format deskryptora zabezpieczeń przy użyciu języka SDDL (Security Descriptor Definition Language) obejmuje następujące odrębne elementy standardowego deskryptora zabezpieczeń:

• Identyfikator SID właściciela.

• SID grupy

• Uznaniowa lista kontroli dostępu (DACL).

• Lista kontroli dostępu systemu (SACL).

W związku z tym opis skryptu INF dla deskryptora zabezpieczeń to:

O:owner-sidG:group-sidD:dacl-flags(ace)(ace)S:sacl-flags(ace)(ace)

Poszczególne wpisy kontroli dostępu opisują dostęp, który ma zostać przyznany lub odrzucony dla określonej grupy lub użytkownika, zgodnie z identyfikatorem zabezpieczeń lub identyfikatorem SID. Na przykład plik INF może zawierać wiersz, taki jak:

"D:P(A;CI;GR;;;BU)(A;CI;GR;;;PU)(A;CI;GA;;;BA)(A;CI;GA;;;SY)(A;CI;GA;;;NS)(A;CI;GA;;;LS)(A;CI;CCDCLCSWRPSDRC;;;S-1-5-32-556)"

Powyższy przykład pochodzi z pliku NETTCPIP.INF z systemu Microsoft Windows XP z dodatkiem Service Pack 1 (SP1).

W tym przypadku nie określono właściciela ani grupy, więc przyjmują one wstępnie zdefiniowane lub domyślne wartości. D wskazuje, że jest to DACL. P wskazuje, że jest to chroniona lista kontroli dostępu (ACL) i nie dziedziczy żadnych praw z deskryptora zabezpieczeń obiektu, który go zawiera. Chroniona lista ACL uniemożliwia dziedziczenie bardziej łagodnych zabezpieczeń z elementu rodzicielskiego. Wyrażenie w nawiasie wskazuje pojedynczy wpis kontroli dostępu (ACE). Wpis kontroli dostępu korzystający z języka SDDL składa się z kilku odrębnych składników rozdzielanych średnikami. W kolejności są one następujące:

• Wskaźnik typu ACE. Istnieją cztery unikatowe typy list kontroli dostępu (DACL) i cztery różne typy list kontroli systemowej (SACL).

• Pole flag używane do opisywania dziedziczenia tej ACE dla obiektów podrzędnych lub inspekcji i zasad alarmu dla SACLs.

• Pole praw wskazuje, które prawa są przyznawane lub odrzucane przez ACE. To pole może określać określoną wartość liczbową wskazującą ogólne, standardowe i określone prawa dotyczące tej ACE lub użyć opisu ciągu wspólnych praw dostępu.

• Identyfikator GUID obiektu, jeśli DACL jest strukturą ACE specyficzną dla obiektu.

• Dziedziczony identyfikator GUID obiektu, jeśli DACL jest strukturą ACE specyficzną dla obiektu

• Identyfikator SID wskazujący jednostkę zabezpieczeń, do której ma zastosowanie ta ACE.

W związku z tym interpretując przykładowy deskryptor zabezpieczeń, litera "A," która prowadzi zapis ACE, wskazuje, że jest to zapis dostępu dozwolonego. Alternatywą jest wpis "odmowa dostępu", który jest używany tylko rzadko i jest oznaczany przez wiodący znak "D". Pole flagi określa Container Inherit (CI), co wskazuje, że ta usługa ACE jest dziedziczona przez obiekty podrzędne.

Wartości pól praw kodują określone prawa, które obejmują prawa ogólne i prawa standardowe. Na przykład "GR" wskazuje "ogólny dostęp do odczytu" i "GA" wskazuje "ogólny dostęp do wszystkiego", z których oba są prawami ogólnymi. Wiele specjalnych praw przestrzega tych ogólnych praw. W powyższym przykładzie "CC" wskazuje tworzenie dostępu podrzędnego, który jest specyficzny dla praw do plików i katalogów. Powyższy przykład zawiera również inne prawa standardowe po ciągu "CC", w tym "DC" dla usuwania dostępu do elementów podrzędnych, "LC" dla uzyskiwania listy elementów podrzędnych, "SW" dla dostępu z prawem własnym, "RP" dla dostępu do właściwości odczytu, "SD" dla standardowego dostępu do usuwania i "RC" dla dostępu do kontroli odczytu.

Ciągi wpisu SID w powyższym przykładzie obejmują "PU" dla użytkowników zasilania, "BU" dla wbudowanych użytkowników, "BA" dla "wbudowanych administratorów, "LS" dla konta usługi lokalnej, "SY" dla systemu lokalnego i "NS" dla konta usługi sieciowej. W powyższym przykładzie użytkownicy otrzymują ogólny dostęp do odczytu w obiekcie. Natomiast wbudowani administratorzy, konto usługi lokalnej, system lokalny i usługa sieciowa mają ogólny dostęp (odczyt, zapis i wykonywanie). Pełny zestaw wszystkich możliwych praw i standardowych ciągów SID są udokumentowane w zestawie Windows SDK.

Te listy ACL zostaną zastosowane do wszystkich obiektów urządzeń utworzonych przez dany sterownik. Sterownik może również kontrolować ustawienia zabezpieczeń określonych obiektów przy użyciu nowej funkcji IoCreateDeviceSecure podczas tworzenia nazwanego obiektu urządzenia. Funkcja IoCreateDeviceSecure jest dostępna w systemie Windows XP z dodatkiem Service Pack 1 i Windows Server 2003 lub nowszym. Za pomocą IoCreateDeviceSecure deskryptor zabezpieczeń, który ma zostać zastosowany do obiektu urządzenia, jest opisany przy użyciu podzestawu pełnego języka definicji deskryptora zabezpieczeń, który jest odpowiedni dla obiektów urządzeń.

Celem zastosowania określonych deskryptorów zabezpieczeń do obiektów urządzeń jest zapewnienie, że odpowiednie kontrole zabezpieczeń są wykonywane względem urządzenia za każdym razem, gdy aplikacja próbuje uzyskać dostęp do samego urządzenia. W przypadku obiektów urządzeń, które zawierają strukturę nazw (na przykład przestrzeń nazw systemu plików), szczegóły zarządzania dostępem do tej przestrzeni nazw urządzeń należą do sterownika, a nie do menedżera we/wy.

Interesującym problemem w tych przypadkach jest sposób obsługi zabezpieczeń na styku między menedżerem we/wy, odpowiedzialnym za kontrolowanie dostępu do obiektu urządzenia sterownika, a sterownikiem urządzenia, który implementuje odpowiednie dla sterownika zasady zabezpieczeń. Tradycyjnie, jeśli otwierany obiekt jest nazwą samego urządzenia, menedżer we/wy wykona pełną kontrolę dostępu względem obiektu urządzenia bezpośrednio przy użyciu deskryptora zabezpieczeń. Jeśli jednak otwarty obiekt wskazuje ścieżkę wewnątrz samego sterownika, menedżer wejścia/wyjścia sprawdzi tylko, czy dostęp do przechodzenia jest udzielany obiektowi urządzenia. Zazwyczaj to prawo do przechodzenia jest przyznawane, ponieważ większość wątków ma przyznany SeChangeNotifyPrivilege, co wiąże się z przyznaniem prawa do przechodzenia w katalogu. Urządzenie, które nie obsługuje struktury nazw, zwykle żąda, aby menedżer we/wy wykonał pełne sprawdzanie zabezpieczeń. W tym celu należy ustawić FILE_DEVICE_SECURE_OPEN bit w polu właściwości urządzenia. Sterownik, który zawiera kombinację takich obiektów urządzeń, powinien ustawić tę charakterystykę dla tych urządzeń, które nie obsługują struktury nazw. Na przykład system plików ustawi tę opcję na nazwanym obiekcie urządzenia (który nie obsługuje struktury nazewnictwa), ale nie ustawi tej opcji na nienazwanych obiektach urządzenia (na przykład woluminie), które obsługują strukturę nazewnictwa. Niepoprawne ustawienie tego bitu jest częstą usterką w sterownikach i może umożliwić nieodpowiedni dostęp do urządzenia. W przypadku sterowników korzystających z interfejsu załącznika (IoAttachDeviceToDeviceStackSafe, na przykład), bit FILE_DEVICE_SECURE_OPEN jest ustawiany, jeśli to pole jest ustawione na urządzeniu, na którym jest dołączany sterownik. Dlatego sterowniki filtrów nie muszą martwić się o ten konkretny aspekt sprawdzania zabezpieczeń.