圖1
Win8開始，Windows引入了新的進程隔離機制AppContainer，MetroAPP以及開啟EPM的IE Tab進程都運行在AppContainer隔離環境，在最新的Win10Pre(9926)上，仍然如此。騰訊反病毒實驗室對AppContainer的工作機制做一深入解讀。
Vista以前的系統，如XP，用安全描述符（簡稱SD，下同）里的DACL（discretionary access control list）來控制用戶和用戶組的訪問權限。
Vista以后，增加了Integrity Mechanism，在SD的SACL(system access control list)里增加一個mandatory label的ACE，擴展了Windows安全體系。默認的控制策略是No-Write-Up，允許較低完整性級別的進程讀訪問較高完整性級別的對象；禁止較低完整性級別的進程寫訪問較高完整性級別的對象。
Win8引入了AppContainer隔離機制，提供了更細粒度的權限控制，能夠阻止對未授權對象的讀寫訪問。
以Win10PreX64(9926)開啟EPM的IE Tab進程為例，看看有哪些變化。
從Process Explorer里可以看到，IE Tab進程的完整性級別不再是Low，而是變成了AppContainer：
圖1
在進程屬性的Security標簽可以看到，增加了標志為AppContainer以及Capability的SID：
圖2
一個AppContainer進程可以訪問的對象，在SD的DACL里增加了額外的ACE。以IE Tab進程的進程對象為例：
圖3
這里我們不討論MetroAPP，主要看看DesktopAPP如何使用AppContainer隔離機制。
仍然以Win10PreX64(9926)開啟EPM的IE Tab進程為例：在IE選項里開啟EPM,下斷點nt!NtCreateLowBoxToken，然后新建IE Tab，命中斷點，截取最上面的幾層調用棧：
圖4
可見，通過CreateProcess這個API就可以創建出AppContainer進程。
看看CreateAppContainerProcessStrW的邏輯片段，把PackageSID String(圖2里標記為AppContainer的SID)和CapabilitySID(圖2里標記為Capability的SID) string轉為SID后，傳給了CreateAppContainerProcessW：
圖5
看看CreateAppContainerProcessW的邏輯片段，把傳入的CapabilitySIDs和PackageSID加入到ProcThreadAttributes，然后通過STARTUPINFOEX結構把ProcThreadAttributes傳給了CreateProcessW。
圖6
圖7
圖8
搞清楚IE Tab進程的創建邏輯，我們就可以創建自己的AppContainer進程了。
直接復用IE的PackageSID和CapabilitySIDs來創建AppContainer進程。如果需要定義自己的PackageSID，可以參考MSDN上的CreateAppContainerProfile等API，這里就不討論了。
成功的創建出了具有AppContainer隔離機制的記事本進程。32位和64位進程都可以。可以自由組合Capability，這里我選擇了IE Tab 6個Capability里的3個。
如果程序在設計時沒有考慮使用AppContainer隔離機制，依賴沒有授權給AppContainer的系統資源，比如系統根目錄，用戶根目錄等，使用AppContainer隔離機制啟動程序會失敗。
為描述方便，AppContainer進程的AccessToken我們簡稱為LowBoxToken（下同）。
下面是一個LowBoxToken的部分信息，可以看到TokenFlags的掩碼位0x4000是置位的，這表示該Token是一個LowBoxToken。我們還可以看到PackageSid、Capabilities等信息（圖2里標志為AppContainer和Capability的SID）。
圖11
DACL的遍歷是在SepNormalAccessCheck/SepMaximumAccessCheck里進行的。這里我們以SepNormalAccessCheck為例，來看一看如何處理AppContianer相關的ACE。
一般來說，在遍歷DACL時，如果滿足以下3個條件中的任意一個，檢查停止。
有一個access-denied ACE明確拒絕了請求訪問權限中的任意一個；
有一個或者多個access-allowed ACEs明確給予了所有的請求訪問權限；
已經檢查完了所有的ACE，但是仍然至少有一個請求訪問權限沒有被明確給予，這種情況下，訪問被拒絕。
從Windows Server 2003開始，DACL里ACE的順序為：
Explicit ACE:Access Denied
Explicit ACE:Access Allowed
Inherited ACE:Access Denied
Inherited ACE:Access Allowed
這個遍歷規則和順序保證了明確拒絕優先于明確允許；明確指定的訪問控制優先于繼承的訪問控制。
以下的內容基于Win10PreX86( 9926)。
在遍歷類型為ACCESS_ALLOWED_ACE_TYPE的ACE時，如果ACE的SID前綴為SePackagePrefixSid(S-1-15-2)或者SeCapabilityPrefixSid(S-1-15-3)，則跳轉到處理AppContainer訪問權限控制的邏輯：
圖12
如果ACE的SID前綴為SePackagePrefixSid(S-1-15-2)，會先看這個SID是否為ALL APPLICATION PACKAGES，這是一個Well known SID
圖13
如果是這個SID，認為匹配成功，不需要再精確比較SID了；否則和Token的PackageSID做精確匹配：
圖14
如果ACE的SID前綴為SeCapabilityPrefixSid(S-1-15-3)，會嘗試匹配Token的Capabilities：
圖15
PackageSID或者Capabilities匹配成功后，會通過a13記錄獲取到的權限以及還剩下未獲取到的權限。a13是上層調用傳進來的結構指針，上一層函數會根據這個結構的值，判斷AppContainer進程是否獲取到了請求的訪問權限。
看看上一層函數SepAccessCheck的邏輯片段，var_AccessLowbox就是圖14/15里的a13。如果PackageSID或者CapabilitieSID給予的權限不能完全覆蓋用戶請求的權限（var_Remaining != 0），則訪問失敗：
圖16
另外，對于No DACL的情況，也有額外的處理邏輯。AppContainer進程訪問No DACL的對象時，是無法獲得訪問權限的：
圖17
所以在Win8及以上系統中，我們如果想要創建一個所有進程（包括開啟EPM的IE Tab ）都能訪問的對象，對于該對象的SD，除了在SACL里指定為低完整性級別外，還要考慮在DACL中顯示的給予everyone以及ALL APPLICATIONS PACKAGE對應的訪問權限控制。
在遍歷類型為ACCESS_DENIED_ACE_TYPE的ACE時，處理邏輯里并沒有區分ACE的SID是否為PackageSID或者CapabilitiesSID。而是簡單使用SepSidInTokenSidHash函數在Token的SidHash/RestrictedSidHash里匹配。如果是PackageSID或者CapabilitiesSID，匹配會失敗，因此該ACE描述的拒絕訪問權限控制不會生效：
圖18
做一個實驗驗證上面的結論，首先我們用AppContainer隔離機制啟動一個記事本，復用IE EPM的PackageSID以及部分Capabilities：
圖19
把C:\Users{當前用戶}\AppData\Local\Packages\windows_ie_ac_001\AC\Temp\test\1.txt設置為下面的權限控制：
圖20
圖21
ACE[0]Mask為0x001F01FF，包含要請求的權限0x00100080 雖然ACE[0]明確的拒絕了 S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394 (圖19里標志為AppContainer的SID)，記事本仍然能成功打開1.txt(ACE1明確給予了ALL APPLICATION PACKAGES 0x001F01FF的訪問權限)。
AppContainer提供了更細粒度的隔離機制，不僅能用于MetroAPP和 IE EPM，當應用程序需要訪問未知第三方內容時，也可以考慮使用AppContainer隔離機制，把對系統的潛在影響降到最低。