Windows 7已经隆重发布，但是很多程序员已经通过RTM等版本尝到了Windows 7的甜处。那么在Windows 7下用户界面特权隔离，将是本文我们介绍的重点。ZJk平坦软件园
我们介绍了操作系统服务的Session 0隔离，通过Session 0隔离，Windows 7实现了各个Session之间的独立和更加安全的互访，使得操作系统的安全性有了较大的提高。从操作系统服务的Session 0隔离尝到了甜头后，雷德蒙的程序员们仿佛爱上了隔离这一招式。现在他们又将隔离引入了同一个Session之中的各个进程之间，带来全新的用户界面特权隔离。 ZJk平坦软件园
用户界面特权隔离ZJk平坦软件园
在早期的Windows操作系统中，在同一用户下运行的所有进程有着相同的安全等级，拥有相同的权限。例如，一个进程可以自由地发送一个Windows消息到另外一个进程的窗口。从Windows Vista开始，当然也包括Windows 7，对于某些Windows消息，这一方式再也行不通了。进程(或者其他的对象)开始拥有一个新的属性——特权等级(Privilege Level)。一个特权等级较低的进程不再可以向一个特权等级较高的进程发送消息，虽然他们在相同的用户权限下运行。这就是所谓的用户界面特权隔离(User Interface Privilege Isolation ，UIPI)。ZJk平坦软件园
UIPI的引入，最大的目的是防止恶意代码发送消息给那些拥有较高权限的窗口以对其进行攻击，从而获取较高的权限等等。这就像一个国家，原本人人平等，大家之间可以互相交流问候，但是后来坏人多了，为了防止坏人以下犯上，获得不该有的权利，就人为地给每个人划分等级，等级低的不可以跟等级高的说话交流。在人类社会，这是一种令人讨厌的等级制度，但是在计算机系统中，这却是一种维护系统安全的合适方式。ZJk平坦软件园
UIPI的运行机制ZJk平坦软件园
在Windows 7中，当UAC(User Account Control)启用的时候，UIPI的运行可以得到最明显的体现。在UAC中，当一个管理员用户登录系统后，操作系统会创建两个令牌对象(Token Object)：第一个是管理员令牌，拥有大多数特权(类似于Windows Vista之前的System中的用户)，而第二个是一个经过过滤后的简化版本，只拥有普通用户的权限。ZJk平坦软件园
默认情况下，以普通用户权限启动的进程拥有普通特权等级(UIPI的等级划分为低等级(low)，普通(normal)，高等级(high)，系统(system))。相同的，以管理员权限运行的进程，例如，用户右键单击选择“以管理员身份运行”或者是通过添加“runas”参数调用ShellExecute运行的进程，这样的进程就相应地拥有一个较高(high)的特权等级。ZJk平坦软件园
这将导致系统会运行两种不同类型，不同特权等级的进程(当然，从技术上讲这两个进程都是在同一用户下)。我们可以使用Windows Sysinternals工具集中的进程浏览器(Process Explorer)查看各个进程的特权等级。 (http://www.microsoft.com/technet/sysinternals)ZJk平坦软件园
下图展示了以不同特权等级运行的同一个应用程序，进程浏览器显示了它们拥有不同的特权等级：
所以，当你发现你的进程之间Windows消息通信发生问题时，不妨使用进程浏览器查看一下两个进程之间是否有合适的特权等级。ZJk平坦软件园
UIPI所带来的限制 ZJk平坦软件园
正如我们前文所说，等级的划分，是为了防止以下犯上。所以，有了用户界面特权隔离，一个运行在较低特权等级的应用程序的行为就受到了诸多限制，它不可以： ZJk平坦软件园
验证由较高特权等级进程创建的窗口句柄 ZJk平坦软件园
通过调用SendMessage和PostMessage向由较高特权等级进程创建的窗口发送Windows消息 ZJk平坦软件园
使用线程钩子处理较高特权等级进程 ZJk平坦软件园
使用普通钩子(SetWindowsHookEx)监视较高特权等级进程 ZJk平坦软件园
向一个较高特权等级进程执行DLL注入 ZJk平坦软件园
但是，一些特殊Windows消息是容许的。因为这些消息对进程的安全性没有太大影响。这些Windows消息包括： ZJk平坦软件园
0x000 - WM_NULL ZJk平坦软件园
0x003 - WM_MOVE ZJk平坦软件园
0x005 - WM_SIZE ZJk平坦软件园
0x00D - WM_GETTEXT ZJk平坦软件园
0x00E - WM_GETTEXTLENGTH ZJk平坦软件园
0x033 - WM_GETHOTKEY ZJk平坦软件园
0x07F - WM_GETICON ZJk平坦软件园
0x305 - WM_RENDERFORMAT ZJk平坦软件园
0x308 - WM_DRAWCLIPBOARD ZJk平坦软件园
0x30D - WM_CHANGECBCHAIN ZJk平坦软件园
0x31A - WM_THEMECHANGED ZJk平坦软件园
0x313, 0x31B (WM_???) ZJk平坦软件园
修复UIPI问题 ZJk平坦软件园
基于Windows Vista之前的操作系统行为所设计的应用程序，可能希望Windows消息能够在进程之间自由的传递，以完成一些特殊的工作。当这些应用程序在Windows 7上运行时，因为UIPI机制，这种消息传递被阻断了，应用程序就会遇到兼容性问题。为了解决这个问题，Windows Vista引入了一个新的API函数ChangeWindowMessageFilter。利用这个函数，我们可以添加或者删除能够通过特权等级隔离的Windows消息。这就像拥有较高特权等级的进程，设置了一个过滤器，允许通过的Windows消息都被添加到这个过滤器的白名单，只有在这个白名单上的消息才允许传递进来。 ZJk平坦软件园
如果我们想容许一个消息可以发送给较高特权等级的进程，我们可以在较高特权等级的进程中调用ChangeWindowMessageFilter函数，以MSGFLT_ADD作为参数将消息添加进消息过滤器的白名单。同样的，我们也可以以MSGFLT_REMOVE作为参数将这个消息从白名单中删除。ZJk平坦软件园
消息包括2中，系统消息的发送和用户自定义消息的发送。ZJk平坦软件园
对于系统消息的处理，非常简单，接受消息的进程需要将该消息加入到白名单中，可以通过下面的代码实现：ZJk平坦软件园
需要在高权限程序开始的地方加入以下代码,指定什么消息可以接受ZJk平坦软件园
typedef BOOL (WINAPI *_ChangeWindowMessageFilter)( UINT , DWORD);ZJk平坦软件园
BOOL CVistaMsgRecvApp::AllowMeesageForVista(UINT uMessageID, BOOL bAllow)//注册Vista全局消息ZJk平坦软件园
{ZJk平坦软件园
BOOL bResult = FALSE;ZJk平坦软件园
HMODULE hUserMod = NULL;ZJk平坦软件园
//vista and laterZJk平坦软件园
hUserMod = LoadLibrary( L"user32.dll" );ZJk平坦软件园
if( NULL == hUserMod )ZJk平坦软件园
{ZJk平坦软件园
return FALSE;ZJk平坦软件园
}ZJk平坦软件园
_ChangeWindowMessageFilter pChangeWindowMessageFilter = (_ChangeWindowMessageFilter)GetProcAddress( hUserMod, "ChangeWindowMessageFilter" );ZJk平坦软件园
if( NULL == pChangeWindowMessageFilter )ZJk平坦软件园
{ZJk平坦软件园
AfxMessageBox(_T("create windowmessage filter failed"));ZJk平坦软件园
return FALSE;ZJk平坦软件园
}ZJk平坦软件园
bResult = pChangeWindowMessageFilter( uMessageID, bAllow ? 1 : 2 );//MSGFLT_ADD: 1, MSGFLT_REMOVE: 2ZJk平坦软件园
if( NULL != hUserMod )ZJk平坦软件园
{ZJk平坦软件园
FreeLibrary( hUserMod );ZJk平坦软件园
}ZJk平坦软件园
return bResult;ZJk平坦软件园
}ZJk平坦软件园
ZJk平坦软件园
对于自定义消息，通常是指大于WM_USER的消息，我们首先必须在系统中注册该消息，然后在调用上面的代码:ZJk平坦软件园
#define WM_MYNEWMESSAGE (WM_USER + 999) ZJk平坦软件园
UINT uMsgBall=::RegisterWindowMessage (WM_MYNEWMESSAGE ) ZJk平坦软件园
if(!uMsgBall) ZJk平坦软件园
return FALSE;ZJk平坦软件园
注册消息通过RegisterWindowMessage实现，函数的参数就是你需要注册的消息值。ZJk平坦软件园
此时，低等级的进程就可以像高等级的进程发送消息了。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/jinhill/archive/2010/07/21/5752870.aspx