使用者介面特權隔離

寫這篇文章源於本人在開發過程中遇到向某個程序傳送訊息失敗而起。

引入uipi的最大目的是為了防止惡意程式傳送訊息給那些擁有較高許可權的視窗，以對其進行攻擊，從而獲取較高的許可權等等。在計算機系統中，這是一種維護系統安全的合適方式。

在windows 7中，當uac(user account control)啟用的時候，uipi的執行可以得到最明顯的體現。在uac中，當乙個管理員使用者登入系統後，作業系統會建立兩個令牌物件(token object)：乙個是管理員令牌，擁有大多數特權(類似於windows vista之前的system中的使用者)，而另乙個是經過過濾後的簡化版本，只擁有普通使用者的許可權。

預設情況下，以普通使用者許可權啟動的程序擁有普通特權等級【uipi的等級劃分為低等級(low)，普通(normal)，高等級(high)，系統(system)】。同樣的，以管理員許可權執行的程序，例如，使用者右鍵單擊選擇「以管理員身份執行」或者是通過新增「runas」引數呼叫shellexecute執行的程序，這樣的程序就相應地擁有乙個較高(high)的特權等級。

這將導致系統會執行兩種不同型別、不同特權等級的程序(當然，從技術上講這兩個程序都是在同一使用者下)。我們可以使用windows sysinternals工具集中的程序瀏覽器(process explorer)檢視各個程序的特權等級。

所以，當你發現你的程序之間windows訊息通訊發生問題時，不妨使用程序瀏覽器檢視一下兩個程序之間是否有合適的特權等級。

正如我們前文所說，等級的劃分，是為了防止以下犯上。所以，有了使用者介面特權隔離，乙個執行在較低特權等級的應用程式的行為就受到了諸多限制，它不可以進行如下操作：

但是，一些特殊windows訊息是被容許的，因為這些訊息對程序的安全性沒有太大影響。這些windows訊息包括：

0x000 - wm_null

0x003 - wm_move
0x005 - wm_size
0x00d - wm_gettext
0x00e - wm_gettextlength
0x033 - wm_gethotkey
0x07f - wm_geticon
0x305 - wm_renderformat
0x308 - wm_drawclipboard
0x30d - wm_changecbchain
0x31a - wm_themechanged
0x313, 0x31b (wm_???)

為了解決這個問題，windows vista引入了新的api函式changewindowmessagefilter和changewindowmessagefilterex。利用這2個函式，我們可以新增或者刪除能夠通過特權等級隔離的windows訊息。這就像擁有較高特權等級的程序，設定了乙個過濾器，被允許通過的windows訊息都將被新增到這個過濾器的白名單，只有在這個白名單上的訊息才允許傳遞進來。

下面對新增/移除白名單功能進行了簡單封裝（uipimsgfilter函式），該函式可以針對特定的窗體新增、移除訊息白名單：

ppx_api bool uipimsgfilter(hwnd hwnd, uint umessageid, bool ballow) 

// if failed, try again.
if (!res) }}
if (hlib != null) 
}else 
return res;
}

使用者特權管理

限定可以使用su的使用者 linux系統中的普通使用者可以通過su和sudo命令擁有超級使用者許可權。在預設情況下，任何普通使用者只要知道超級使用者root的密碼，都可以通過su root變成root許可權，那麼這樣就存在一些安全隱患。我們可以設定僅有屬於某個組的使用者可以通過su變成root，例如...

shell進入特權模式 使用者,特權,全域性模式

了解使用者模式 特權模式和全域性模式 首先我們啟動路由器這是我們發現命令列變為 r1 使用者模式的標誌 現在我們來看一看在使用者模式下我們可以進行哪些操作 r1 exec commands access enable create a temporary access list entry call...

介面隔離原則

一 isp簡介 isp inte ce segregation principle 使用多個專門的介面比使用單一的總介面要好。乙個類對另外乙個類的依賴性應當是建立在最小的介面上的。乙個介面代表乙個角色，不應當將不同的角色都交給乙個介面。沒有關係的介面合併在一起，形成乙個臃腫的大介面，這是對角色和介面...