深度解析Windows最新進(jìn)程隔離機(jī)制AppContainer

3.已經(jīng)檢查完了所有的ACE，但是仍然至少有一個(gè)請求訪問權(quán)限沒有被明確給予，這種情況下，訪問被拒絕。

從Windows Server 2003開始，DACL里ACE的順序?yàn)椋?

Explicit     ACE:AccessDenied‍‍ ‍‍Explicit     ACE:AccessAllowed‍‍ ‍‍Inherited ACE:Access Denied‍‍ ‍‍Inherited ACE:Access Allowed

這個(gè)遍歷規(guī)則和順序保證了明確拒絕優(yōu)先于明確允許；明確指定的訪問控制優(yōu)先于繼承的訪問控制。

以下的內(nèi)容基于Win10PreX86(9926)。

ACCESS_ALLOWED_ACE_TYPE

在遍歷類型為ACCESS_ALLOWED_ACE_TYPE的ACE時(shí)，如果ACE的SID前綴為SePackagePrefixSid(S-1-15-2)或者SeCapabilityPrefixSid(S-1-15-3)，則跳轉(zhuǎn)到處理AppContainer訪問權(quán)限控制的邏輯：

圖12

如果ACE的SID前綴為SePackagePrefixSid(S-1-15-2)，會先看這個(gè)SID是否為ALLAPPLICATION PACKAGES，這是一個(gè)Well known SID

圖13

如果是這個(gè)SID，認(rèn)為匹配成功，不需要再精確比較SID了；否則和Token的PackageSID做精確匹配：

圖14

如果ACE的SID前綴為SeCapabilityPrefixSid(S-1-15-3)，會嘗試匹配Token的Capabilities：

圖15

PackageSID或者Capabilities匹配成功后，會通過a13記錄獲取到的權(quán)限以及還剩下未獲取到的權(quán)限。a13是上層調(diào)用傳進(jìn)來的結(jié)構(gòu)指針，上一層函數(shù)會根據(jù)這個(gè)結(jié)構(gòu)的值，判斷AppContainer進(jìn)程是否獲取到了請求的訪問權(quán)限。

看看上一層函數(shù)SepAccessCheck的邏輯片段，var_AccessLowbox就是圖14/15里的a13。如果PackageSID或者CapabilitieSID給予的權(quán)限不能完全覆蓋用戶請求的權(quán)限（var_Remaining != 0），則訪問失�。�