Uwp 仅限制驾驶员访问具有CustomCapability+；签署SCCD

我有一个UMDF驱动程序，它提供UWP应用程序访问的IOCTL命令。 UWP应用程序被提交到商店，并带有适当的自定义功能和签名SCCD，以便访问UMDF驱动程序

我从中了解到，这允许UWP应用程序访问驱动程序及其IOCTL，因此当其他UWP应用程序尝试访问时，它们将被拒绝。但是，SCCD没有明确说明Win32应用程序仍然能够访问IOCTL，我认为这违背了拥有自定义功能和SCCD的目的

鉴于这个问题，我理解我必须以另一种方式拒绝来自Win32应用程序的请求

有一个

GetApplicationUserModelId

函数，我们想用它来确定应用程序是否不是UWP应用程序。这需要pID，我们可以使用

WdfRequestGetRequestorProcessId

获得它。但是，获取此pID的进程句柄需要访问其他进程的内存。由于UMDF驱动程序没有权限，因为它不拥有进程，因此在尝试调用OpenProcess时返回

错误\u ACCESS\u DENIED

，即使访问权限为

进程\u QUERY\u LIMITED\u INFORMATION

建议为了打开另一个本地进程的句柄并获得完全访问权限，必须启用

SeDebugPrivilege

特权。我相信这样做会给司机带来更大的安全风险，因此，强行通过可能不是一个好主意

---

如果有其他替代方法，或其他类型的描述符，或任何类似的方法可以支持限制win32应用程序使用IOCTLs的目标，则可以使用该函数。此函数创建一个事件回调函数，UMDF可以使用该函数模拟请求进程的访问权限

请注意，应该是

SecurityImpersonation

。这需要在INF文件中声明，并在

WdfRequestImpersonate

函数参数中提供<现在可以从回调函数中调用code>OpenProcess

---

请注意，

WdfRequestImpersonate

在回调函数结束之前不会返回，并且模拟仅限于回调函数的内容。

由于Win32应用程序是中IL，因此它们能够调试并将代码注入低IL应用程序（如UWP应用程序），因此，您设置的任何障碍都可以绕过：Win32应用程序可以启动带有SCCD的UWP应用程序，然后修改其代码以执行Win32应用程序希望执行的任何操作。谢谢您的见解，我理解。但是，考虑到有此限制和没有此限制的巨大差异，添加一些东西仍然具有深度防御价值，因为它增加了攻击所需的复杂性。因此，我认为这仍然是一个有效的选择，可以降低风险（但不能像您指出的那样消除风险）。