我可以为那些知道互斥锁密码的进程全局创建一个 Windows 互斥锁吗？
Can I create a Windows mutex globally for those processes which know the password of the mutex?
我想使用 WinAPI、CreateMutex() 和 OpenMutex() 创建 Windows 互斥。但是出于安全考虑，我希望知道 "password" 或硬编码魔术代码的那些进程打开互斥体。我不希望每个进程都访问互斥量。
例如，
创建名称为 "Globel\cd689f00-0462-11e5-b939-0800200c9a66" 的互斥锁。
所以只有知道互斥锁名称的进程才能访问这个互斥锁。但这不是一个好的解决方案，因为您可以简单地使用 Winobj.exe 并且您仍然有机会找到这个互斥体。
我希望这个互斥体受到 ACL（访问控制列表）之类的保护。问题是，我找不到为 ACL 创建自己的 SID 的方法。
这是我所知道的和我想要的：
1. 我知道我可以通过将互斥量命名为 "Global\MyMutexName" 来让许多进程访问它。
2.我也尝试去理解MSDN上提到的ACL和SID。但我仍然找不到创建自己的 SID 的方法（也许这没有意义？）。
3. 我不想将我的进程提升为管理员。
你会让 Windows 创建一个新的 SID；不要试图自己创建一个。使用该 SID，您可以构建一个 ACL（访问控制列表），该列表授予对持有该 SID 的所有进程的访问权限，并（隐含地）拒绝其他所有人的访问权限。然后可以将此 ACL 应用于保护它的互斥量。
现在要获得访问权限，您需要为该 SID 创建一个模拟令牌。如果我理解 MSDN，这个过程是打开你的线程令牌，通过 SetTokenInformation 设置 TokenUser，然后通过 SetThreadToken 应用修改后的令牌。
现在在检查互斥体的 ACL 时使用此模拟令牌。
MSDN 对创建有效用户 SID 的过程并不完全清楚；在上述过程中可能需要将 "User SID" 替换为 "Group SID"。
您尝试做的事情对于 Windows 使用的安全模型来说是不自然的。权限的授予始终基于 运行 执行可执行文件的人，而不是可执行文件本身。但是，根据您的情况，可能会有合适的选择。
如果涉及的所有进程都在同一个用户的上下文中，那么您可以使用 IPC（例如，命名管道）来识别您的 "friendly" 个进程，并 DuplicateHandle() 传递一个处理进程之间未命名的互斥锁。
如果进程必须在不同的用户上下文中，一种选择是让系统服务 运行在特权上下文中充当代理。当然，这需要以管理员权限安装系统服务，但这通常是可以接受的；只需要做一次。
如果应用程序必须是可移植的（无需安装，或者无需管理员权限即可安装）并且必须跨越用户边界，那么我认为您必须使用 IPC 来实现您自己的互斥体。当然，那样效率很低。
请记住，在任何这些情况下，恶意用户仍然可以访问互斥体 - 您能做的最好的事情就是稍微增加一点难度。例如，如果您使用实际的互斥锁，攻击者可以枚举其中一个进程的句柄、识别互斥锁并复制句柄。 （或者简单地将恶意代码注入所谓的 "friendly" 进程之一以直接使用句柄。）甚至 IPC 也可能被监视和复制。
您应该认真考虑边际安全收益是否值得显着增加复杂性。 IMO，不太可能。
（顺便说一句，正确的解决方案是让系统服务完成所有需要访问互斥体的工作；用户 运行 的应用程序通常是什么都不做的瘦客户端但提供 GUI。）
我想使用 WinAPI、CreateMutex() 和 OpenMutex() 创建 Windows 互斥。但是出于安全考虑，我希望知道 "password" 或硬编码魔术代码的那些进程打开互斥体。我不希望每个进程都访问互斥量。
例如， 创建名称为 "Globel\cd689f00-0462-11e5-b939-0800200c9a66" 的互斥锁。 所以只有知道互斥锁名称的进程才能访问这个互斥锁。但这不是一个好的解决方案，因为您可以简单地使用 Winobj.exe 并且您仍然有机会找到这个互斥体。 我希望这个互斥体受到 ACL（访问控制列表）之类的保护。问题是，我找不到为 ACL 创建自己的 SID 的方法。
这是我所知道的和我想要的： 1. 我知道我可以通过将互斥量命名为 "Global\MyMutexName" 来让许多进程访问它。 2.我也尝试去理解MSDN上提到的ACL和SID。但我仍然找不到创建自己的 SID 的方法（也许这没有意义？）。 3. 我不想将我的进程提升为管理员。
你会让 Windows 创建一个新的 SID；不要试图自己创建一个。使用该 SID，您可以构建一个 ACL（访问控制列表），该列表授予对持有该 SID 的所有进程的访问权限，并（隐含地）拒绝其他所有人的访问权限。然后可以将此 ACL 应用于保护它的互斥量。
现在要获得访问权限，您需要为该 SID 创建一个模拟令牌。如果我理解 MSDN，这个过程是打开你的线程令牌，通过 SetTokenInformation 设置 TokenUser，然后通过 SetThreadToken 应用修改后的令牌。
现在在检查互斥体的 ACL 时使用此模拟令牌。
MSDN 对创建有效用户 SID 的过程并不完全清楚；在上述过程中可能需要将 "User SID" 替换为 "Group SID"。
您尝试做的事情对于 Windows 使用的安全模型来说是不自然的。权限的授予始终基于 运行 执行可执行文件的人，而不是可执行文件本身。但是，根据您的情况，可能会有合适的选择。
如果涉及的所有进程都在同一个用户的上下文中，那么您可以使用 IPC（例如，命名管道）来识别您的 "friendly" 个进程，并 DuplicateHandle() 传递一个处理进程之间未命名的互斥锁。
如果进程必须在不同的用户上下文中，一种选择是让系统服务 运行在特权上下文中充当代理。当然，这需要以管理员权限安装系统服务，但这通常是可以接受的；只需要做一次。
如果应用程序必须是可移植的（无需安装，或者无需管理员权限即可安装）并且必须跨越用户边界，那么我认为您必须使用 IPC 来实现您自己的互斥体。当然，那样效率很低。
请记住，在任何这些情况下，恶意用户仍然可以访问互斥体 - 您能做的最好的事情就是稍微增加一点难度。例如，如果您使用实际的互斥锁，攻击者可以枚举其中一个进程的句柄、识别互斥锁并复制句柄。 （或者简单地将恶意代码注入所谓的 "friendly" 进程之一以直接使用句柄。）甚至 IPC 也可能被监视和复制。
您应该认真考虑边际安全收益是否值得显着增加复杂性。 IMO，不太可能。
（顺便说一句，正确的解决方案是让系统服务完成所有需要访问互斥体的工作；用户 运行 的应用程序通常是什么都不做的瘦客户端但提供 GUI。）