跨进程 PostMessage、UIPI 限制和 UIAccess="true"

我错过了什么? 解决方案 Win32 API 文档中涵盖了您所描述的内容:PostMessage 功能如果函数失败，返回值为零.要获取扩展错误信息，请调用 GetLastError.当达到限制时，GetLastError 返回 ERROR_NOT_ENOUGH_QUOTA.当消息被 UIPI 阻止时，使用 GetLastError 检索到的最后一个错误设置为 5(拒绝访问).UIPI 在哪里 用户界面权限隔离:什么是用户界面权限隔离(UIPI)这也称为 UI 权限级别隔离 (UIPI).作为 Vista 中安全举措的一部分，具有 UI 的应用程序将以三种不同的权限级别运行.应用程序窗口可以与其他同级别或更低级别的窗口交互，但不能与更高级别/权限的应用程序交互.只有在更高权限的应用程序通过调用 ChangeWindowMessageFilter() 的消息明确允许时，低权限模式才能向更高权限的应用程序发送消息.此外，较低权限的应用程序只能读取较高权限应用程序拥有的 HWND.Internet Explorer 是在最低权限级别运行的示例进程.参考链接:http://msdn2.microsoft.com/en-us/library/ms632675.aspxhttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/AccProtVista.aspUIPI 通过阻止以下行为来防止较低权限的进程访问较高权限的进程.较低权限的进程不能: – 执行更高进程权限的窗口句柄验证.– SendMessage 或 PostMessage 到更高权限的应用程序窗口.这些应用程序编程接口 (API) 会返回成功，但会以静默方式丢弃窗口消息.– 使用线程钩子附加到更高权限的进程.– 使用日志钩子来监控更高权限的进程.– 执行动态链接库 (DLL) – 注入更高权限的进程.启用 UIPI 后，以下共享 USER 资源仍会在不同权限级别的进程之间共享.– 桌面窗口，实际拥有屏幕表面– 桌面堆只读共享内存– 全局原子表– 剪贴板正如文档所说，更高权限的应用程序需要使用 ChangeWindowMessageFilter() 允许来自较低权限应用程序的特定窗口消息:从用户界面特权隔离 (UIPI) 消息过滤器中添加或删除消息.在 Windows 7 及更高版本上，使用 ChangeWindowMessageFilterEx() 代替:修改用户界面特权隔离 (UIPI) 消息过滤器针对指定窗口.因此，在您的情况下，在您的更高特权进程调用 RegisterWindowMessage() 以获取注册的消息 ID 后，它需要将该 ID 传递给 ChangeWindowMessageFilter/Ex() 以便从较低特权的进程接收该消息.For security reasons the UI module for my application runs with a high mandatory integrity level. Everything in it works great, except one thing. For compatibility with older versions I need to be able to let users issue command line calls to the UI module.At the moment this mechanism works as such:The shortcut from Windows Explorer calls my module, say as such:path-to-module\module.exe -op="a, s, r"When module.exe process parses this command line it then locates the running copy of UI module (or another copy of self) using FindWindow by its unique class name. It then sends it a registered message using PostMessage API.Then the running UI module (with high integrity level), when it receives the message, processes it accordingly.The problem is that because the running copy of UI module has high integrity level, it cannot receive messages from a lower integrity level, or the copy of the module when it's run by the Windows Explorer to parse a shortcut command, which makes it run with medium integrity level.To address this I found this UIAccess flag (see here, and scroll down to where it says "UIAccess for UI automation applications".)So my assumptions were that if I set this flag and code-sign my UI module:it will be able to bypass the UIPI restriction I described above.It runs just fine:But what I see is that PostMessage API in the algorithm I described above still fails with ERROR_ACCESS_DENIED when I call it from the module running with medium integrity level.What have I missed there? 解决方案 What you describe is covered in the Win32 API documentation:PostMessage function If the function fails, the return value is zero. To get extended error information, call GetLastError. GetLastError returns ERROR_NOT_ENOUGH_QUOTA when the limit is hit. When a message is blocked by UIPI the last error, retrieved with GetLastError, is set to 5 (access denied).Where UIPI is User Interface Privilege Isolation: What is User Interface Privilege Isolation (UIPI) This is also known as UI Privilege Level Isolation (UIPI). As part of the secure initiatuve in Vista, applications with UI will run in three different levels of privilege. Application windows can interact with others windows of the same or lower levels, but cannot interact with applications at higher level/permission. Lower privilege modes can send messages to higher privileged applications only if explicitly allowed by the higher privilege application with a message calling ChangeWindowMessageFilter(). Also lower privileged applications can only read a HWND owned by a higher privileged application. Internet Explorer is an example process that runs at the lowest privilege level. Reference Links: http://msdn2.microsoft.com/en-us/library/ms632675.aspx http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/AccProtVista.asp UIPI prevents lower privilege processes from accessing higher privilege processes by blocking the following behavior. A lower privilege process cannot: – Perform a window handle validation of higher process privilege. – SendMessage or PostMessage to higher privilege application windows. These application programming interfaces (APIs) return success but silently drop the window message. – Use thread hooks to attach to a higher privilege process. – Use Journal hooks to monitor a higher privilege process. – Perform dynamic link library (DLL)–injection to a higher privilege process. With UIPI enabled, the following shared USER resources are still shared between processes at different privilege levels. – Desktop window, which actually owns the screen surface – Desktop heap read-only shared memory – Global atom table – ClipboardAs the documentation says, the higher privilege application needs to use ChangeWindowMessageFilter() to allow specific window messages from lower privilege applications: Adds or removes a message from the User Interface Privilege Isolation (UIPI)message filter.On Windows 7 and later, use ChangeWindowMessageFilterEx() instead: Modifies the User Interface Privilege Isolation (UIPI) message filter for a specified window.So, in your case, after your higher privileged process calls RegisterWindowMessage() to get a registered message ID, it needs to pass that ID to ChangeWindowMessageFilter/Ex() in order to receive that message from lower privileged processes. 这篇关于跨进程 PostMessage、UIPI 限制和 UIAccess="true"的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！