在裝置物件上套用安全性描述元
大部分的驅動程式會使用 I/O 管理員針對其裝置物件套用的存取控制,以保護自己不受不當存取。 大部分驅動程式最簡單的方法是在安裝驅動程式時套用明確的安全性描述元。 在 INF 檔案中,這類安全性描述元是由 AddReg 區段中的「安全性」專案描述。 如需用來描述安全性描述項之完整語言的詳細資訊,請參閱Microsoft Windows SDK檔中的安全性描述元定義語言。
使用安全性描述元定義語言 (SDDL) 的安全性描述元基本格式包含下列標準安全性描述元的不同片段:
擁有者 SID。
群組 SID。
Discretionary 存取控制清單 (DACL)。
系統存取控制清單 (SACL)。
因此,安全性描述元 INF 腳本內的描述如下:
O:owner-sidG:group-sidD:dacl-flags(ace)(ace)S:sacl-flags(ace)(ace)
個別存取控制專案描述要授與或拒絕特定群組或使用者的存取權限,如安全性識別碼或 SID 所指定。 例如,INF 檔案可能包含一行,例如:
"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)"
上述範例來自 NETTCPIP。來自 Microsoft Windows XP Service Pack 1 (SP1) 系統的 INF 檔案。
在此實例中,沒有指定擁有者或群組,因此它們預設為預先定義的或預設值。 D表示這是 DACL。 P表示這是受保護的 ACL,而且不會從包含物件的安全性描述元繼承任何許可權。 受保護的 ACL 可防止父代繼承更寬鬆的安全性。 括號運算式表示 ACE) 的單一存取控制專案 (。 使用 SDDL 的存取控制專案是由數個不同的分號分隔元件所組成。 依序,它們如下所示:
ACE 的類型指標。 DACL 有四個唯一的類型,以及 SCL 的四種不同類型。
旗 標 欄位,用來描述此 ACE 的子物件繼承,或 SCL 的稽核和警示原則。
Rights欄位會指出 ACE 授與或拒絕哪些許可權。 此欄位可以指定特定數值,指出適用于此 ACE 的泛型、標準和特定許可權,或使用通用存取權限的字串描述。
如果 DACL 是物件特定的 ACE 結構,則為物件 GUID。
如果 DACL 是物件特定的 ACE 結構,則為繼承的物件 GUID
SID,指出此 ACE 套用的安全性實體。
因此,解譯範例安全性描述元,前置 ACE 的 「A」 表示這是「允許存取」專案。 替代方式是「拒絕存取」專案,它只會不常使用,並以前置 「D」 字元表示。 旗標欄位會指定 Container Inherit (CI) ,這表示此 ACE 是由子物件繼承。
許可權欄位值會編碼包含一般許可權和標準許可權的特定許可權。 例如,「GR」 表示「泛型讀取」存取,而 「GA」表示「全部」存取,這兩者都是泛型許可權。 一些特殊許可權遵循這些一般許可權。 在上述範例中,「CC」 表示建立子存取權,這是檔案和目錄許可權特有的。 上述範例也包含 「CC」 字串之後的其他標準許可權,包括刪除子存取的 「DC」、用於清單子存取的 「LC」、用於自我許可權存取的 「SW」、用於讀取屬性存取的 「RP」、標準刪除存取的 「SD」,以及讀取控制存取的 「RC」。
上述範例中的 SID 專案字串包含 Power Users 的 「PU」、適用于內建使用者的 「BU」、適用于本機服務帳戶的 「BA」、本機服務帳戶的 「LS」、本機系統的 「SY」,以及網路服務帳戶的 「NS」。 因此,在上述範例中,使用者會在 物件上獲得泛型讀取權限。 相反地,內建系統管理員、本機服務帳戶、本機系統和網路服務都會獲得一般存取權, (讀取、寫入和執行) 。 Windows SDK 記載了所有可能的許可權和標準 SID 字串的完整集合。
這些 ACL 會套用至指定驅動程式所建立的所有裝置物件。 驅動程式也可以在建立具名裝置物件時,使用新的函式 IoCreateDeviceSecure來控制特定物件的安全性設定。 IoCreateDeviceSecure函式可在 Windows XP Service Pack 1 和 Windows Server 2003 和更新版本上使用。 使用 IoCreateDeviceSecure時,會使用適用于裝置物件的完整安全性描述元定義語言子集來描述要套用至裝置物件的安全性描述元。
將特定安全性描述元套用至裝置物件的目的是確保每當應用程式嘗試存取裝置本身時,就會對裝置進行適當的安全性檢查。 對於包含名稱結構的裝置物件, (檔案系統的命名空間,例如) ,管理此裝置命名空間存取權的詳細資料屬於驅動程式,而不是 I/O 管理員。
在這些情況下,有一個有趣的問題是如何處理 I/O 管理員之間的安全性,負責檢查驅動程式裝置物件的存取權和裝置驅動程式,以實作任何適用于驅動程式的安全性原則。 傳統上,如果開啟的物件是裝置本身的名稱,I/O 管理員會直接使用其安全性描述元,對裝置物件執行完整存取檢查。 不過,如果開啟的物件指出驅動程式本身內的路徑,I/O 管理員只會檢查以確保周遊存取權被授與裝置物件。 一般而言,此周遊許可權是授與的,因為大部分的執行緒都已獲得 SeChangeNotifyPrivilege,這與授與目錄周遊許可權相對應。 不支援名稱結構的裝置通常會要求 I/O 管理員執行完整安全性檢查。 這是藉由在裝置特性欄位中設定 FILE_DEVICE_SECURE_OPEN 位來完成。 包含這類裝置物件混合的驅動程式,應該為不支援名稱結構的裝置設定這項特性。 例如,檔案系統會在其具名裝置物件上設定此選項, (不支援命名結構) ,但不會在磁片區 (未命名的裝置物件上設定此選項,例如) 支援命名結構。 無法正確設定此位是驅動程式中的常見錯誤,而且可以允許不適當的裝置存取。 對於使用附件介面的驅動程式 (IoAttachDeviceToDeviceStackSafe,例如) ,如果驅動程式所連接的裝置中設定此欄位, 就會設定FILE_DEVICE_SECURE_OPEN 位。 因此,篩選驅動程式不需要擔心安全性檢查的這個特定層面。