压在透明的玻璃上c-国产精品国产一级A片精品免费-国产精品视频网-成人黄网站18秘 免费看|www.tcsft.com

Win8開始，Windows引入了新的進(jìn)程隔離機(jī)制AppContainer，MetroAPP以及開啟EPM的IE Tab進(jìn)程都運(yùn)行在AppContainer隔離環(huán)境，在最新的Win10Pre(9926)上，仍然如此。騰訊反病毒實(shí)驗(yàn)室對(duì)AppContainer的工作機(jī)制做一深入解讀。

AppContainer帶來(lái)的變化

Vista以前的系統(tǒng)，如XP，用安全描述符（簡(jiǎn)稱SD，下同）里的DACL（discretionaryaccess control list）來(lái)控制用戶和用戶組的訪問(wèn)權(quán)限。

Vista以后，增加了IntegrityMechanism，在SD的SACL(system access control list)里增加一個(gè)mandatory label的ACE，擴(kuò)展了Windows安全體系。默認(rèn)的控制策略是No-Write-Up，允許較低完整性級(jí)別的進(jìn)程讀訪問(wèn)較高完整性級(jí)別的對(duì)象；禁止較低完整性級(jí)別的進(jìn)程寫訪問(wèn)較高完整性級(jí)別的對(duì)象。

Win8引入了AppContainer隔離機(jī)制，提供了更細(xì)粒度的權(quán)限控制，能夠阻止對(duì)未授權(quán)對(duì)象的讀寫訪問(wèn)。

以Win10PreX64(9926)開啟EPM的IE Tab進(jìn)程為例，看看有哪些變化。

從ProcessExplorer里可以看到，IE Tab進(jìn)程的完整性級(jí)別不再是Low，而是變成了AppContainer：

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

在進(jìn)程屬性的Security標(biāo)簽可以看到，增加了標(biāo)志為AppContainer以及Capability的SID：

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

一個(gè)AppContainer進(jìn)程可以訪問(wèn)的對(duì)象，在SD的DACL里增加了額外的ACE。以IE Tab進(jìn)程的進(jìn)程對(duì)象為例：

如何使用AppContainer隔離機(jī)制

這里我們不討論MetroAPP，主要看看DesktopAPP如何使用AppContainer隔離機(jī)制。

仍然以Win10PreX64(9926)開啟EPM的IE Tab進(jìn)程為例：在IE選項(xiàng)里開啟EPM,下斷點(diǎn)nt!NtCreateLowBoxToken，然后新建IE Tab，命中斷點(diǎn)，截取最上面的幾層調(diào)用棧：

可見，通過(guò)CreateProcess這個(gè)API就可以創(chuàng)建出AppContainer進(jìn)程。

看看CreateAppContainerProcessStrW的邏輯片段，把PackageSIDString(圖2里標(biāo)記為AppContainer的SID)和CapabilitySID(圖2里標(biāo)記為Capability的SID) string轉(zhuǎn)為SID后，傳給了CreateAppContainerProcessW：

看看CreateAppContainerProcessW的邏輯片段，把傳入的CapabilitySIDs和PackageSID加入到ProcThreadAttributes，然后通過(guò)STARTUPINFOEX結(jié)構(gòu)把ProcThreadAttributes傳給了CreateProcessW。

搞清楚IE Tab進(jìn)程的創(chuàng)建邏輯，我們就可以創(chuàng)建自己的AppContainer進(jìn)程了。

直接復(fù)用IE的PackageSID和CapabilitySIDs來(lái)創(chuàng)建AppContainer進(jìn)程。如果需要定義自己的PackageSID，可以參考MSDN上的CreateAppContainerProfile等API，這里就不討論了。

成功的創(chuàng)建出了具有AppContainer隔離機(jī)制的記事本進(jìn)程。32位和64位進(jìn)程都可以。可以自由組合Capability，這里我選擇了IE Tab6個(gè)Capability里的3個(gè)。

如果程序在設(shè)計(jì)時(shí)沒有考慮使用AppContainer隔離機(jī)制，依賴沒有授權(quán)給AppContainer的系統(tǒng)資源，比如系統(tǒng)根目錄，用戶根目錄等，使用AppContainer隔離機(jī)制啟動(dòng)程序會(huì)失敗。

AppContainer的訪問(wèn)權(quán)限控制

為描述方便，AppContainer進(jìn)程的AccessToken我們簡(jiǎn)稱為L(zhǎng)owBoxToken（下同）。

下面是一個(gè)LowBoxToken的部分信息，可以看到TokenFlags的掩碼位0×4000是置位的，這表示該Token是一個(gè)LowBoxToken。我們還可以看到PackageSid、Capabilities等信息（圖2里標(biāo)志為AppContainer和Capability的SID）。

DACL

DACL的遍歷是在SepNormalAccessCheck/SepMaximumAccessCheck里進(jìn)行的。這里我們以SepNormalAccessCheck為例，來(lái)看一看如何處理AppContianer相關(guān)的ACE。

一般來(lái)說(shuō)，在遍歷DACL時(shí)，如果滿足以下3個(gè)條件中的任意一個(gè)，檢查停止。

1.有一個(gè)access-denied ACE明確拒絕了請(qǐng)求訪問(wèn)權(quán)限中的任意一個(gè)；

2.有一個(gè)或者多個(gè)access-allowed ACEs明確給予了所有的請(qǐng)求訪問(wèn)權(quán)限；

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

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

Explicit???? ACE:AccessDenied

Explicit???? ACE:AccessAllowed

Inherited ACE:Access Denied

Inherited ACE:Access Allowed

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

以下的內(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訪問(wèn)權(quán)限控制的邏輯：

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

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

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

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

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

另外，對(duì)于No DACL的情況，也有額外的處理邏輯。AppContainer進(jìn)程訪問(wèn)No DACL的對(duì)象時(shí)，是無(wú)法獲得訪問(wèn)權(quán)限的：

所以在Win8及以上系統(tǒng)中，我們?nèi)绻胍獎(jiǎng)?chuàng)建一個(gè)所有進(jìn)程（包括開啟EPM的IE Tab ）都能訪問(wèn)的對(duì)象，對(duì)于該對(duì)象的SD，除了在SACL里指定為低完整性級(jí)別外，還要考慮在DACL中顯示的給予everyone以及ALL APPLICATIONS PACKAGE對(duì)應(yīng)的訪問(wèn)權(quán)限控制。

ACCESS_DENIED_ACE_TYPE

在遍歷類型為ACCESS_DENIED_ACE_TYPE的ACE時(shí)，處理邏輯里并沒有區(qū)分ACE的SID是否為PackageSID或者CapabilitiesSID。而是簡(jiǎn)單使用SepSidInTokenSidHash函數(shù)在Token的SidHash/RestrictedSidHash里匹配。如果是PackageSID或者CapabilitiesSID，匹配會(huì)失敗，因此該ACE描述的拒絕訪問(wèn)權(quán)限控制不會(huì)生效：

做一個(gè)實(shí)驗(yàn)驗(yàn)證上面的結(jié)論，首先我們用AppContainer隔離機(jī)制啟動(dòng)一個(gè)記事本，復(fù)用IE EPM的PackageSID以及部分Capabilities：

把C:\Users\{當(dāng)前用戶}\AppData\Local\Packages\windows_ie_ac_001\AC\Temp\test\1.txt設(shè)置為下面的權(quán)限控制：

ACE[0]Mask為0x001F01FF，包含要請(qǐng)求的權(quán)限0×00100080

雖然ACE[0]明確的拒絕了

S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394(圖19里標(biāo)志為AppContainer的SID)，記事本仍然能成功打開1.txt(ACE[1]明確給予了ALL APPLICATION PACKAGES 0x001F01FF的訪問(wèn)權(quán)限)。

結(jié)束語(yǔ)

AppContainer提供了更細(xì)粒度的隔離機(jī)制，不僅能用于MetroAPP和 IE EPM，當(dāng)應(yīng)用程序需要訪問(wèn)未知第三方內(nèi)容時(shí)，也可以考慮使用AppContainer隔離機(jī)制，把對(duì)系統(tǒng)的潛在影響降到最低。