了解 Windows 的檔案與登錄使用權限

了解 Windows 的檔案與登錄使用權限

轉載至 http://msdn.microsoft.com/zh-tw/magazine/cc982153.aspx

John R. Michener

本文討論下列主題： 存取控制清單 使用者權限 檔案系統權限 登錄及其權限

本文使用下列技術： Windows Server 2008

 目錄

物件安全性描述元
了解安全性描述元 string_ace
標準權限與特定權限
完整性標籤與其使用方式
Object_guid 與 inherit_object_guid
解譯安全性描述元 string_ace
Windows 資源保護
設定安全的檔案系統權限
管理登錄與其權限
總結

只要系統中發生事件，就會有主體 (可能是代替使用者或服務執行動作的處理序或執行緒) 在物件上採取動作。檔案、目錄及登錄機碼，都是我們熟知的物件。Windows 的基本安全性機制會在允許作業繼續之前，由受信任的系統元件先檢查權限 (Permission) 與權限/權利 (Right) (AccessCheck)。因此，您可以藉由設定權限 (Permission) 與權限/權利 (Right) 來管理系統的行為。由於若不了解幕後真正發生的動作，將無法適當地設定權限，因此我將先討論物件的安全性設定和處理的方式，然後再討論如何設定其值。

在探討技術細節之前，我要先使用 Windows 存取控制清單 (Access Control List，ACL) GUI 來看看 Windows Server 2008 中，系統磁碟機根目錄的權限。如果我開啟 [Windows 檔案總管]，選取 [安全性] 索引標籤，並在本機磁碟 (C:) 上按一下滑鼠右鍵，然後選取 [內容]，就會看到系統管理員擁有完全控制權限。如果按一下 [群組 (Group)] 或使用者名稱底下的 [SYSTEM]，會看到 SYSTEM 也擁有完全控制權限。當我按一下 [群組 (Group)] 或使用者名稱底下的 [使用者 (User)] 之後，會看到權限情況並非如此簡單：在 [圖 1] 中，系統上的使用者群組擁有讀取和執行、列出、讀取...等等的權限。按一下 [進階] 按鈕可以檢視使用者群組相關權限的詳細資料 (請參閱 [圖 2])。

圖 1 本機磁碟機 C: 的使用者權限

圖 2 磁碟機 C: 之使用者權限的進階檢視 (按一下影像以放大圖片)

使用者群組的成員可以在系統磁碟機的根目錄中建立資料夾，以及附加資料至檔案。如果按一下 [編輯] 按鈕，會看到子資料夾有另一個「特別」授與的權限，如 [圖 3] 所示。此作業需要系統管理員權限。

圖 3 使用者特殊權限的編輯檢視

如您所見，根據預設會允許一般使用者從 Windows Server 2008 系統磁碟機的根目錄建立子資料夾，以及新增內容至這些資料夾。Windows Server 2008 上的使用者群組成員可以使用此功能，因為某些協力廠商軟體會假設這些權限是存在的，而 Microsoft 不想破壞應用程式的相容性。

接下來讓我們討論這些問題的技術面，以及它們在呈現給使用者之 GUI 介面的幕後情形。在 Windows 中，所有具名物件都有安全性描述元，這會提供擁有者的相關資訊，並且列出哪些使用者和主體擁有指定的權限。它還可以指定必須將哪些物件的存取，記錄到系統事件日誌中。

允許主體 (使用者、處理序...等等) 對物件或資源執行哪些作業的相關資訊，會在稱為 ACL 的資料結構中指定。ACL 會列舉誰 (哪個主體) 對特定物件擁有何種存取權。判別存取控制清單 (Discretionary Access Control List，DACL) 是一種 ACL，這會允許物件的擁有者變更物件。存取物件時，就會比較安全性描述元和主體的權限，以確認要求的存取動作是允許的。

請注意，Windows 也支援物件的系統存取控制清單 (System Access Control List，SACL)，並且已在許多版本中使用 SACL 的設定，來決定哪些事件要記錄到稽核記錄中。Windows Server 2008 與 Windows Vista 的 SACL 已經擴充，能夠包含完整性層級資訊。

此完整性標籤會用於建立「低 (Low)」標籤，標記在 LowRights Internet Explorer 中使用的 Internet Explorer 處理序。「系統 (System)」與「高 (High)」標籤則用於保護重要的系統資源。Windows 訊息幫浦 (Message Pump) 會根據訊息的完整性層級來篩選訊息。例如，中層級處理序不會接收從低層級處理序送來的訊息，而高層級處理序不會接收從低層級和中層級處理序送來的訊息。

目前，完整性層級的保護只能說是一項安全措施，而非可提供安全性保證的真正安全性防護機制。在未來的版本中，此安全措施很可能會成為真正的安全性防護機制，因為其防禦力將大幅增加。

Windows 和其他最新的作業系統一樣，都依賴 DACL 來決定一般的存取控制決策。本文主要討論的是 DACL。系統在決定是否允許主體對物件執行某項操作時，會檢查許多事項：主體的權限、主體的權杖，以及物件的安全性描述元。物件的二進位安全性描述元，會使用主體的權杖傳遞給 AccessCheck 常式。其中會準備一個要求的存取遮罩位元向量，代表必須授與這些存取權限，存取檢查才會成功。它和主體的安全性描述元一起傳遞給 AccessCheck 常式，常式則會檢查使用者的安全性權杖，並將主體的權限 (通常是以角色或成員資格為基礎，例如系統管理員) 結合要求的存取和物件的 DACL 一起考慮。

如果主體的權限可滿足要求的存取，就會授與存取權。否則，會依序檢查 DACL 存取控制項目 (Access Control Entry，ACE)。一旦安全性系統能夠證實允許所有要求的存取元件，它會立即傳回成功，若發現有任何存取元件被拒絕，則會立即傳回失敗。

因此，ACE 的 DACL 清單應該適當地排序。標準 (正式) 順序為先安排明確拒絕，然後是明確允許，一般 (群組) 拒絕和群組允許。如果未使用正式順序，可能會發生意想不到的允許或拒絕。

物件安全性描述元

安全性描述元是二進位資料結構，因此會依賴安全性描述元的字串格式，來提供易於人們閱讀的文字格式。字串格式安全性描述元是以 Null 值結束的字串代表，其中會含有權杖，以指示四個主要元件：擁有者 (O:)、主要群組 (G:)、DACL (D:) 及 SACL (S:)，如 [圖 4] 所示。

圖 4 安全性描述元

安全性識別元 (Security Identifier，SID) 已結構化以提供剖析資訊，其中包含 96 個位元的隨機資訊 (也可能包含 32 個位元的序列計數)，做為擁有者的唯一識別碼。string_ace (以字串格式表示的 ACE) 是在 DACL 中明確授與或拒絕權限，以及在 SACL 中設定原則的結構。每個 string_ace 都會以括號括住，並具有下列結構：

複製程式碼

   (ace_type;ace_flags;rights;object_guid;inherit_
   object_guid;account_sid)

其中只需呈現正確存取要操作之物件所需的授權。安全性描述元中，通常會省略 owner_sid 與 group_sid。如果沒有在建立時明確指定，安全性描述元的擁有者欄位會設定為呼叫物件建立之主體的 SID。群組欄位則會設定為主體之安全性權杖的主要群組。如果不必稽核物件或設定完整性標籤，就不會呈現 SACL。

string_ace 中只會包含必要的欄位 (最小的集合是 ace_type、權限及主體，通常是 account_sid)。通常不會有 object_guid 與 inherit_object_guid。系統會從第一個 ACE 依序剖析到最後一個 ACE，直到授與或拒絕存取權為止。因此，ACE 的順序很重要。「拒絕權限」應放在「允許權限」之前。

未包含 ACE 的 ACL 是空的 DACL。由於 ACE 會授與物件指定的主體存取權，因此沒有人能夠存取 DACL 為空白的物件。沒有 DACL 的物件稱為具有 NULL DACL。具有 NULL DACL 的物件並未受到保護，每個人都可以完全控制這類物件。因此，請不要設定空的或 NULL DACL。

接下來讓我們花點時間來看看實際可行的安全性描述元是什麼樣子。以下是 Windows Server 2008 系統磁碟機根目錄的安全性描述元 (請注意 cacls 是調查及設定 ACL 的傳統命令列常式，已由 icacls 取代。可惜的是，icacls 並不支援以標準安全性描述元定義語言 (Security Descriptor Definition Language，SDDL) 輸出結果的命令列參數 (/S 旗標)，只有 cacls 才能使用這個參數：

複製程式碼

C:\>cacls c:/ /s
c:\"D:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;0x1200a9;;;BU)(A;CI;LC;;;BU)(A;CIIO;DC;;;BU)(A;OICIIO;GA;;;CO)"

根據我們對安全性描述元的了解，可以從前置的「D:」看出並未宣告擁有權或群組成員資格，而且描述元是 DACL。DACL 已受到保護：因為設定了「P」和 Windows NT 5.0 繼承旗標。然後是一些必須解碼的 ace_string。

了解安全性描述元 string_ace

回想我在前面示範的 string_ace 格式。允許的 ace_type 如 [圖 5] 中所定義，而允許的 ace_flag 如 [圖 6] 中所定義。繼承的 ace_flag 是 ACE 繼承的支配要素。

圖 5 允許的 ace_type

圖 6 允許的 ace_flag

ACE 權限會由表示 ACE 控制之存取權限的字串來表示。此字串可以是存取權限的十六進位字串表示法，例如「0x7800003F」，也可以是 Rights 字串的串連，例如「CCLCSWLOCRRC」，後者會在稍後解釋。十六進位表示法和相關的位元值如 [圖 7] 所示。

圖 7 ACL 存取遮罩

系統會針對所有的物件，使用單一的 ACE 權限點陣圖表示法。並非所有位元對各種物件都有意義。其中只會套用適合物件的權限。標準權限是所有安全物件共同的權限。一般權限是方便為各種物件指定相同目的之權限的簡短形式。一般權限的規格，會對應到適當的特定權限集。指定 SACL 時，也會使用 ACE 權限欄位將完整性標籤編碼。各種物件可用的權限如 [圖 8] 所列。

圖 8 一般權限

有許多大致上相等的權限對應，在使用時並無區別。完全控制 (FC) 等於 Generic_All (GA)。File All (FA) 是檔案系統的完全控制宣告。Key All (KA) 是登錄的完全控制宣告。泛型宣告經常會用來代替較適當的宣告，不過會適當地對應至適當的檔案系統或登錄機碼宣告。SDDL 運算式經常會混用這些用語，因此您必須認識其等效性。

標準權限與特定權限

許多物件都可以有指派的權限。除了檔案與目錄之外，還有登錄機碼、處理序、桌面...等等。完整清單請參閱 [圖 A] 至 [圖 J]。由於我們將要討論檔案系統與登錄的權限，因此 [圖 9] 和 [圖 10] 提供了這些物件的特定權限。

圖 9 特定的檔案權限

圖 10 特定的登錄權限

完整性標籤與其使用方式

我已經提過，如果有完整性標籤存在，標籤是儲存在物件的 SACL 中。物件隱含具有中度完整性，因此若是沒有完整性標籤，物件的完整性就會是中度層級。同樣地，若是安全性權杖沒有完整性標籤，其完整性也會是中度層級。低度完整性標籤用於標示低權限處理序，例如 LowRights Internet Explorer 和相關的不受信任物件。「高 (High)」與「系統 (System)」的層級會用於隔離這些物件，亦即與中度和低度層級的處理序及物件隔離。完整性標籤如 [圖 11] 所示。

圖 11 完整性標籤

Object_guid 與 inherit_object_guid

Object_guid 與 inherit_object_guid 是用於指定 Active Directory 中之物件的安全性。保護檔案系統或登錄時並不會使用。ACE 字串之 ace_type 欄位中的「OA」和「OD」，分別對應至 object-allow 和 object-deny ACE。在此情況下，object_guid 會保存授與權限之物件的 guid，而 inherit_object_guid 則會保存來源物件的 guid，且會從它繼承權限。

ACE 結構中的 account_sid 欄位，表示授與或拒絕 ACE 中指定之存取權限的安全性主體。Account_sid 欄位可能會保存一個 SID (這是一個長結構的識別碼，基本上對人們沒有意義)，或是保存一個簡短形式的「SID 字串」表示法，用於一般帳戶。只要可能，就會使用一般帳戶的 SID 字串表示法，讓系統更容易閱讀。一般或大家熟知之帳戶及其 SID 字串的表格如下面的 [圖 J] 所示。

擁有者權限的 OW 宣告，是 Windows Server 2008 與 Windows Vista 的新功能。以往，物件的建立者/擁有者 (Creator/Owner，CO) 具有該物件的標準讀取控制 (Read Control，RC) 和 Write_DAC (WD) 權限，讓擁有者得以設定物件的安全性。如果使用者是群組的成員，並建立大量的物件，這就會造成問題。如果該使用者離開群組，仍將擁有這些物件的控制權，因為他是這些物件的擁有者，因此會被授與 RC 加上 Write_DAC 權限。OW 擁有者 ACE 限制的存在，會阻止隱含授與擁有者 RC/WD，除非在 ACL 中明確授與擁有者 ACE 其他任何相關的 ACE。這可以緩合此一安全性問題。

解譯安全性描述元 string_ace

系統磁碟機根目錄的 cacls 輸出為：

複製程式碼

"D:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;0x1200a9;;;BU)(A;CI;LC;;;BU)(A;CIIO;DC;;;BU)
    (A;OICIIO;GA;;;CO)"

加以剖析以便於閱讀，即得：

複製程式碼

"D:PAI
(A;OICI;FA;;;SY)
(A;OICI;FA;;;BA)
(A;OICI;0x1200a9;;;BU)(A;CI;LC;;;BU)(A;CIIO;DC;;;BU)
(A;OICIIO;GA;;;CO)"

這是現代檔案系統集具有自動繼承旗標的受保護 DACL。受保護的旗標表示不會繼承可繼承的父系授權；DACL 會受到保護而不從物件的父系繼承。在此案例中並沒有父系，因為它是根目錄。

內建的系統管理員 (Administrator) 和系統 (System) 針對檔案 (由於物件繼承) 和目錄 (由於容器繼承或 CI) 都被授與了可繼承的 File All。這表示此 DACL 在根目錄底下的所有檔案與目錄，都會遞迴地被授與 File All，除非有受保護的 DACL 阻止了繼承的情況，若是如此，就必須檢查受保護的 DACL 中的授權。CO 會被授與 Generic_All，這對應至 File All，且適用於根目錄底下的檔案與目錄 (由於 inherit-only 旗標)。

對內建使用者的授權要有趣多了。第一個 string_ace 會套用至根目錄及其下的檔案和目錄，並允許 List、Read、ReadEA、Traverse、Execute、ReadAttr、ReadControl 及 Sync。第二個 string_ace 會授與根目錄及其下的 AddSubDir (由於 IO - inherit-only 旗標)，而第三個 string_ace 則允許根目錄底下之目錄的 AddFile。這和您使用 Windows 檔案總管的 ACL 圖形化介面來瀏覽這些權限時看到的相同。

Windows 資源保護

從 Windows Server 2008 與 Windows Vista 開始，元件就會在其 Microsoft 程式碼簽署根所簽署的資訊清單中，宣告需要的安全性設定。資訊清單會指定與檔案相關的 ACL 和其他權限。因此，安裝元件時，它會具有適當的安全性設定。除此之外，作業系統的檔案會使用 Windows 資源保護 (Windows Resource Protection，WRP) 來保護，以防止系統管理員因疏忽而損壞。WRP 會依賴新的系統層級實體 Trusted Installer，來擁有及管理系統檔案和資料夾。

Windows Vista 中新增了可讓一般使用者安裝授權元件的好工具。因此不再需要進階使用者 (Power User) 角色，所以移除了包含進階使用者 (Power User) SID 的 ACE 例項。進階使用者 (Power User，PU) 群組仍然存在，但是已掃描元件資訊清單，並針對找到的例項，刪除了有授權給 PU 的所有例項。

接下來讓我們檢視系統目錄，以查看新的權限。這也是閱讀 SDDL 的另一個很好的練習：

複製程式碼

C:\>cacls c:\windows /s
C:\Windows "D:PAI(A;;FA;;;S-1-5-80-956008885-3418522649-18310
38044-1853292631-2271478464)(A;CIIO;GA;;;S-1-5-80-956008885-3
418522649-1831038044-1853292631-2271478464)(A;;0x1301bf;;;SY}
(A;OICIIO;GA;;;SY)(A;;0x1301bf;;;BA)(A;OICIIO;GA;;;BA)(A;;0x1200a9;;;BU)
(A;OICIIO;GXGR;;;BU)(A;OICIIO;GA;;;CO)"

Trusted Installer 的 SID 為 S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464。使用 TI 做為簡短形式，發現下列內容：

複製程式碼

C:\Windows "D:PAI
(A;;FA;;;TI)(A;CIIO;GA;;;TI)
(A;;0x1301bf;;;SY)(A;OICIIO;GA;;;SY)
(A;;0x1301bf;;;BA)(A;OICIIO;GA;;;BA)
(A;;0x1200a9;;;BU)(A;OICIIO;GXGR;;;BU)
(A;OICIIO;GA;;;CO)" 

解譯之後，您看到它是受保護的 ACE，使用 Windows NT 5.0 繼承模型套用至 C:\Windows。

Trusted Installer 被授與 C:\Windows 的完全控制，並授與 C:\Windows 底下之所有子容器的 Generic_All (因為它是 CI，僅限繼承)。

系統 (System) 與系統管理員 (Administrator) 都被授與 C:\Windows 的 Read、Write、Append、ReadEA、WriteEA、Execute、ReadAttr、WriteAttr、Del、RCtl 及 Sync，= SDGRGWGX。這是 Generic_All 減掉 Write_Owner 與 Write_DAC；系統管理員 (Administrator) 與系統 (System) 被授與變更擁有者或 ACL 之能力以外的一切權限。「BA」與「SY」具有子檔案與目錄物件的 Generic_All。

由於管理員具有取得擁有權的權限，因此無論如何仍可宣告 WriteOwnership 並取得控制權。系統管理員 (Administrator) 與系統 (System) 的安全性是相等的。不過使用此權限，有心的系統管理員可以規避 WRP ACL 控制。

CO 也具有子檔案與目錄物件的 Generic_All。內建使用者具有 C:\Windows 的 Read、ReadEA、Execute、ReadAttr、RCtl 及 Sync，= GRGX，以及 C:\Windows 之下的子目錄及其檔案的 GRGX。

所有系統檔案與資料夾，都具有授與 Trusted Installer 完全控制之受保護的 ACL。Trusted Installer 對檔案的控制，並不是在系統根目錄上的宣告中表示，而是在 Windows 元件的個別宣告中表示。

設定安全的檔案系統權限

您對於檔案系統 ACL 如何作用及如何讀取它們已有一些概念，接著來看看如何設定這些 ACL。如果要安裝應用程式，應該安裝至預設的程式檔案 (Program Files) 位置。此位置的預設 ACL 會適當地賦予系統管理員 (Administrator) 和本機系統 (Local System) 完全控制。

如果您將應用程式安裝至其他位置，或者授與使用者選擇其應用程式偏好位置的能力，會有這樣的問題：其他磁碟機和系統磁碟機的非系統與非應用程式區域的預設 ACL 不夠安全。在這些情況下，您必須以適當的受保護 DACL，明確地設定資料夾的 ACL。安裝應用程式最簡單且最安全的選擇，是複製程式檔案 (Program Files) 資料夾的安全性設定。如果您選擇不複製，請設定 DACL 讓非系統管理員無法變更可執行檔的 DACL 或擁有權，而且無法寫入、附加或刪除包含可執行檔之目錄中的檔案。

設定 DACL 時，基本規則是不要讓系統管理員或其他使用者來執行使用者所編寫的程式碼。如果資料夾預期是受信任的，通常是因為位於受信任區域之一 (Windows、程式檔案 (Program Files)...等等)，這就是個問題。如此做會允許提高權限 (Elevation of Privilege，EoP) 至系統管理員 (Administrator)，而增加跨使用者攻擊的風險。因此，如果使用者可以對這類資料夾寫入檔案，則不應該讓其他使用者和系統管理員能夠執行這些檔案。

乍看之下，不論什麼時候，似乎都不應該讓使用者寫入 Windows、System、Program Files...等等的資料夾。不過有些合理的原因需要這麼做。最常見的原因是為了要記錄錯誤記錄檔的資料。如果可執行檔是在使用者的認證下執行，且必須記錄錯誤，則需要錯誤記錄檔/記錄檔資料夾的寫入/附加存取權 (如果在多重使用者的系統上記錄錯誤至個別使用者位置，記錄資料會散佈在系統各處，而不是與可執行檔關聯。應用程式與服務通常會寫入共用資料夾或登錄機碼)。您會在登錄中發現相同的問題，其錯誤資訊常會由以使用者權限執行的處理序，儲存在指定的電腦登錄機碼中。

請不要將使用者可寫入檔案與可執行檔混在一起。必須信任的檔案 (例如可執行檔) 和不應該信任的檔案 (可能由不受信任使用者編寫的任何檔案)，應該使用不同的目錄。適當地在目錄使用 ACL - 系統管理員可控制執行檔，而使用者可讀取/執行，但是不能寫入。登錄機碼與子機碼也適用相同的原則。

用戶端與伺服器在此不同：通常會假設伺服器系統管理員的知識，遠比以系統管理員身分執行的使用者更豐富。伺服器管理員知道不應該執行系統不受信任區域中的程式碼。建立一個命名慣例以隔離系統中的資料檔案和可執行檔，即可提供系統管理員關於可執行檔可信任度的指引，亦即記錄檔的子目錄是不可信任的，因此使用者不應該擁有建立或修改這些子目錄的能力，因為如此可能讓他們欺騙安全命名規則。

在用戶端環境中，欺騙管理使用者執行程式碼會容易許多。由於系統管理員比較天真，所以可由使用者寫入的目錄，都不應該允許系統管理員的執行權限，以防止使用者安裝可執行檔，然後欺騙系統管理員的使用者執行檔案來危害系統。例如，您的應用程式或服務若必須儲存以使用者權限寫入的記錄資訊，您就應該建立記錄檔的子目錄來保存該資料。此子目錄不應該允許系統管理員執行權限。執行方式之一是為每個人新增前置明確拒絕，例如 D;OI;WP;;;WD。這可在允許使用者寫入或修改檔案的目錄中，防止跨使用者的攻擊。

有許多情況下，使用者可能會共用資料 (雖然我們不希望使用者共用及執行共用區域中的程式碼)。例如，家庭使用者 (或他的相片檢視應用程式) 很可能建立 C:\Photos 之類的資料夾。使用者會希望允許多位使用者寫入此資料夾，並讓多位使用者編輯此資料夾中的各相片。Windows Vista 系統磁碟機根目錄上的預設 ACL 支援此作業。另一種常見的共用情況，是使用者放置資料供其他使用者讀取的資料夾。只有資料的建立者可以刪除或修改資料，但是其他使用者可能會複製資料，然後編輯複本。這是共用讀取情況，也是 Windows Server 2008 上系統磁碟機的預設情況。

假設有一種情況，您選擇鎖定系統磁碟機和 (尤其是) 共用的 ACL 資料夾。您就必須選擇適合這兩種相當常見情況的 ACL。我們希望系統管理員能夠管理物件，也希望防止與執行這些資料夾中之程式碼相關的安全性問題 (請注意此處的 ACE 甚至會防止擁有者從這些資料夾執行程式碼)。

以下是 Shared Read ACE：

複製程式碼

D:P(D;OI;WP;;;WD)(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)(A;OICI;FA;;;CO)(A;CI;0x1200af;;;AU)(A;OI;GR;;;AU)

以下則是 Collaborative ACE：

複製程式碼

D:P(D;OI;WP;;;WD)(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)(A;OICI;FA;;;CO)(A;OICI;SDGRGW;;;AU)

請注意，這兩個 ACL 一開始都會針對所有使用者 (Everyone) 拒絕執行 ACE、物件繼承 (將其套用至檔案) 開始，以防止使用者系統和跨使用者攻擊。然後會授與系統管理員 (Administrator)、系統 (System) (系統其實並不真的需要它) 和 CO 完全控制 = File All。

針對 Shared Read 的情況，會因為對 CI 授與的限制而授與已驗證的使用者 List、AddFile、AddSubDir、ReadEA、Traverse、ReadAttr、RCtl 及 Sync，對目錄也會授與一樣的權限，並分別對所有檔案授與一般讀取 (Generic Read)。針對 Collaborative 的情況，會授與已驗證使用者檔案與目錄的刪除 (Delete)、一般讀取 (Generic Read) 以及一般寫入 (Generic Write)。

管理登錄與其權限

Windows 會將大部分的狀態資訊儲存在 Windows 登錄中。登錄資料存放區稱為 Hive，資料會儲存在其中的機碼和子機碼內，這兩者都視為容器 (子機碼不視為物件)。

使用者專屬的資料，會儲存在適當的 Hive Key Users (HKEY_USERS) 使用者區段。這些資料如您所想的，大部分都可由使用者寫入。在任何工作階段中，HKey_Current_User (HKCU) 會指向適當的 HKEY_USERS 區段。

系統與電腦資訊是儲存在 HKEY_LOCAL_MACHINE (HKLM) Hive 中。HKLM 中有包含各種系統服務的資訊，其中大部分現在都在各種本機服務 (Local Service) 或網路服務 (Network Service) 群組下，以有限的權限執行。服務與應用程式可以將狀態資訊儲存在其登錄機碼中。此資訊應該儲存在子機碼中，可以是服務機碼或服務機碼下的機碼。服務機碼不應該使用 ACL，才能讓服務能夠在自己的服務機碼上 SetKey (或 WDac 或 WOwn，但這可能會造成這類的攻擊)，因為這可讓服務指向另一個可執行檔。這樣的錯誤可能會對服務主機造成潛在的 EoP，因為服務控制管理員會在系統載入時，載入其中所指向的可執行檔。

對於 HKLM 之 DACL 的一般原則是，不應該讓使用者寫入或修改此資料或相關的 ACL 與擁有權。如同設定系統區域中的檔案系統 DACL 一樣，在使用者或限制內容下執行的應用程式或服務若需要記錄錯誤資訊，就會發生錯誤記錄的例外。這類情況的解決方法類似於檔案系統中相同的問題，要為這些資訊建立個別的機碼，然後適當地設定 ACL。因此機密資訊可以透過 ACL 的設定，由受信任的主體 (系統管理員 (Administrator)、系統 (System)...等等) 來處理，使記錄檔資料可在需要時適當地寫入。

您應當避免使用者修改受信任的參數 (例如，關閉防毒軟體或反惡意程式碼服務)，或者竄改使用者或系統管理員使用的工具。假設當呼叫記事本時，會載入 C:\windows\notepad.exe。C:\windows 上預設的 ACL 不允許攻擊者修改可執行檔。如果攻擊者可以重新寫入記事本圖示到其可執行檔的連結，攻擊者就能夠造成其他檔案的載入，例如 C:\tools\load_rootkit.exe。這可能會載入 Rootkit，然後載入記事本，讓使用者察覺不到危害。

如果攻擊者可以透過登錄驅動連結，檔案系統上的防護 ACL 就會完全失效。您也要注意受限制系統服務對其他系統服務的攻擊。在 Windows Vista 與 Windows Server 2008 中，服務會依其需要的權限區分為群組。此一服務隔離機制所提供的深入防護功能，需要由服務權限的設定來配合，使服務無法互相竄改，尤其是跨服務群組。

正如同我們需要防止使用者新增或連結至惡意可執行檔一樣，我們也必須防止服務變更其權限和功能。服務上的 ChangeConf 權限必須限制為系統管理員 (Administrator)、系統 (System) 或 Trusted Installer，因為此權限允許擁有者變更服務的權限。

總結

Windows 提供非常豐富的權限控制集，可用來允許作業、封鎖作業，以及針對新威脅提供深入防護功能。如此豐富的控制存取能力，無可避免地會有一定的複雜度。

遵循相關的原則，即可幫助您避免問題。例如，系統預設值是適當的折衷。您應該使用預設值。如果要在程式檔案 (Program Files) 之外的位置安裝應用程式，請使用程式檔案 (Program Files) 的 ACL。在某些情況下，您可能需要比預設值更拘謹的設定，例如，進一步刪減磁碟機上的使用者預設授權；不過請記住，如果您真的這麼做，就必須做好心理準備，因為可能會需要尋找及處理潛在的應用程式相容性問題。

最重要的原則是，系統管理員 (Administrator) 或系統 (System) 帳戶都不應該執行使用者可以編寫或修改的程式碼，或者指向這種程式碼。另一項重要的原則是，不應該讓使用者執行或指向其他使用者可以寫入或修改的程式碼。以上原則可以避免本文討論的所有安全性問題。如果您所做的任何變更都有遵循這些原則，基本上就可以避免最為嚴重的安全性問題。

如需存取控制元件的詳細資訊，請參閱 MSDN 上的《存取控制元件》。如需 ace_string 存取遮罩元件的詳細資訊，請參閱 MSDN《ACCESS_MASK》文章，其中包含檔案、目錄、登錄機碼及共用區段之特定權限的指引。關於受限制之 SID 的詳細資訊，請參閱 MSDN《受限制的權杖》文章。

權限的完整清單

圖 A 標準權限

圖 B 檔案與目錄的特定權限

圖 C 檔案對應與登錄的特定權限

圖 D 服務控制管理員與服務的特定權限

圖 E 處理序與執行緒的特定權限

圖 F 視窗工作站與桌面的特定權限

圖 G 符號連結與事件的特定權限

圖 H 旗號 (Semaphore) 與 Mutex 的特定權限

圖 I 管道與權杖的特定權限

圖 J 常見或熟知的帳戶及其 SID 字串

John R. Michener 是 Microsoft 的資深安全性專案經理。他在大約 5 年前加入 Microsoft 的 Windows Security 團隊。John 在系統安全性方面有 20 多年的經驗，並參與了三個安全性產品的開發。他也是 Windows 軟體保證 (Software Assurance) 團隊的密碼編譯與權限專家。您可以透過電子郵件地址 jmichene@microsoft.com 與他連絡。