我能为那些知道互斥体密码的进程创建一个全局的Windows互斥体吗？

Question

我能为那些知道互斥体密码的进程创建一个全局的Windows互斥体吗？

3

我想使用WinAPI的CreateMutex()和OpenMutex()创建一个Windows互斥锁。但出于安全考虑，我希望只有知道“密码”或硬编码魔术代码的进程才能打开该互斥锁。我不希望每个进程都可以访问该互斥锁。

例如，使用名称为“Global\cd689f00-0462-11e5-b939-0800200c9a66”的互斥锁进行创建。因此，只有知道互斥锁名称的进程才能访问该互斥锁。但这并不是一个好的解决方案，因为您仍然可以使用Winobj.exe，并且仍有一些机会找到该互斥锁。我希望通过类似ACL（访问控制列表）的东西来保护此互斥锁。问题是，我找不到创建自己SID的方法。

以下是我所了解的和所需的： 1. 我知道我可以通过命名为“Global\MyMutexName”之类的方式使互斥锁被许多进程访问。 2. 我也尝试理解MSDN上提到的ACL和SID。但我仍然找不到创建自己SID的方法（也许这没有意义？）。 3. 我不想升级我的进程到管理员。

- Calvin Wu

2个回答

3

您需要让Windows创建一个新的SID，不要尝试自己创建。有了这个SID，您可以构建一个ACL（访问控制列表），授予所有持有该SID的进程访问权限，并（隐式地）拒绝其他人的权利。然后，可以将此ACL应用于保护它的互斥体。

现在，要获得访问权限，您需要为该SID创建一个模拟令牌。如果我理解MSDN的话，该过程是打开您的线程令牌，通过SetTokenInformation设置TokenUser，然后通过SetThreadToken应用修改后的令牌。

检查互斥体的ACL时，现在使用这个模拟令牌。

MSDN对创建有效用户SID的过程并不完全清楚；可能需要在上述过程中将“用户SID”替换为“组SID”。

- MSalters

这是否意味着我需要使用 SetThreadToken 进行模拟以获取互斥体，然后在释放互斥体后需要使用 RevertToSelf？ - Calvin Wu

您IP地址为143.198.54.68，由于运营成本限制，当前对于免费用户的使用频率限制为每个IP每72小时10次对话，如需解除限制，请点击左下角设置图标按钮（手机用户先点击左上角菜单按钮）。 - MSalters

好的，我明白了。但是这个模拟操作可能会对性能产生影响吗？我还有一个问题。最后一句话的意思是我可以为自己创建一个“组SID”，其他人无法获取这个“组SID”吗？ - Calvin Wu

我从来没有想过尝试使用SetTokenInformation直接更改令牌中的安全主体。这可能会奏效，但是如果确实如此，那么它肯定需要特权，即使是管理员也没有。您可能还需要复制令牌并在副本上工作，而不是在已经正在使用的令牌上工作。由于 OP 不希望被提升权限，因此这绝对不符合他的要求。 - Harry Johnston

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Harry Johnston · Accepted Answer

你正在尝试的操作不符合Windows使用的安全模型。权限总是基于运行可执行文件的用户而不是可执行文件本身来授予的。但是，根据您的情况，可能有适当的选项。

如果所有涉及的进程都在同一用户上下文中，则可以使用IPC（例如命名管道）来识别您的“友好”进程，并使用DuplicateHandle()在进程之间传递未命名互斥体的句柄。

如果进程必须处于不同的用户上下文中，则一种选择是运行在特权上下文中的系统服务作为代理。当然，这需要使用管理员特权安装系统服务，但通常可以接受；只需要做一次即可。

如果应用程序必须具有可移植性（无需安装或能够在没有管理员访问权限的情况下安装），并且必须跨越用户边界，则认为您必须使用IPC来实现自己的互斥体。当然，那将非常低效。

请记住，在这些情况下，恶意用户仍然可以访问互斥量——你能做的最好的事情就是使其变得更加困难。例如，如果你使用实际的互斥量，攻击者可以枚举其中一个进程的句柄，识别出互斥量，并复制该句柄。（或者直接将恶意代码注入其中一个“友好”的进程中，直接使用该句柄）。甚至IPC也可能遭到窥探和复制。

你应该认真考虑边际安全收益是否值得显著增加复杂性，我认为很可能不值得。

顺便说一下，正确的解决方案是由系统服务完成需要访问互斥量的所有工作；用户运行的应用程序通常只是提供GUI的轻客户端。