C++ 从非特权应用程序（通过RPC）为其他用户打开HKCR和HKCU

在非特权应用程序（通过本地RPC）中实现跨用户注册表访问时遇到问题。情况如下：

• 我正在编写一个沙盒应用程序，它可以访问RPC服务器，但几乎无法访问注册表
• 我有一个RPC服务器作为LocalSystem在与沙盒应用程序相同的机器上运行。使用的RPC传输是LRPC（ncalrpc）
• 我想使该应用程序能够浏览注册表的各个部分（包括其他用户拥有的注册表项），而无需编辑注册表项上的ACL即可直接访问该应用程序

当前，应用程序调用RPC服务器，该服务器打开一个指向请求路径的HKEY，然后使用将其传递回应用程序

• 这适用于HKLM和HKU。应用程序接收HKEY并可以使用它枚举子键和读取值
• 对于那些蜂巢的子键，它也很有效。应用程序获取子项并可以枚举其内容
• 我想要的东西将处理HKCU（完全是每个用户）和HKCR（系统

  类
  根目录和每个用户
  类
  根目录的联合）的用户，而不是LocalSystem（RPC服务的运行方式）

到目前为止，我所尝试的：

• 让应用程序尝试打开根密钥本身，然后将它们（通过

  DuplicateHandle

  ）传递到RPC服务器，而不是预定义的密钥。
  • 这甚至对应用程序自己的用户都不起作用；应用程序可以打开密钥（访问权限非常有限），但服务器显然无法打开在根HKEY中传递的这些密钥的子密钥（可能是由于原始HKEY的低权限？）
  • 这对其他用户根本不起作用；应用程序没有权限使用（无法获取其他用户的令牌）或（应用程序无法模拟其他用户）等功能
• 将应用程序调用

  RegOpenUserClassesRoot

  和

  RegOpenCurrentUser

  放在服务器上，并将这些HKEY传回应用程序（通过

  DuplicateHandle

  ，与处理所有HKEY的方式相同）。然后，应用程序存储返回的密钥，并在需要打开这些密钥的子密钥时将其复制到服务器。这也不起作用（导致拒绝访问错误）

我可以尝试的事情：

• 当客户端要求服务器获取用户的HKCU或HKCR时，让服务器按需获取所需的注册密钥。缺点是重复调用的开销更大（除非进行大量缓存，否则无法重用密钥），优点是避免了

  DuplicateHandle

  循环滴漏（不知何故，这可能是问题所在…）。似乎不太可能真正解决问题，但我还没有尝试
• 更改注册表项ACL以直接授予应用程序所需的访问权限。这仍然要求服务器能够打开用户试图识别的注册表项。我甚至不确定每个用户的HKCR联合视图是否存在，直到有人试图打开该密钥
• 再次检查代码，寻找到目前为止我还没有发现的bug，缩小了问题可能原因的范围。到目前为止，这还不能解决这个问题，尽管它确实让我解决了另一个与这个RPC服务器不同的问题（这是我编写的第一个大规模MSRPC代码），所以这次我可能会很幸运。如果我尝试过的其中一件事情本应该奏效，但没有奏效，那么这显然也是应该做的事情

---

任何在这方面有经验的人都知道我做错了什么？

你的责任划分错了。将访问注册表所需的所有代码放在服务器中，应用程序中唯一需要的代码是UI。（这也有助于缓解您引入的安全漏洞。）然而，FWIW应该能够通过直接将HKCU作为HKU的子密钥（其名称为用户的SID）打开来处理HKCU。HKCR可能是一个失败的原因，因为我认为这是某种伪句柄，因此不能跨进程复制。@HarryJohnston我试图将通过RPC进行大量调用和传递大量数据对性能的影响降至最低，从而实现来回传递HKEY而不是数据缓冲区的目标。LRPC速度相当快，性能也不那么敏感。不过，开设香港大学的观点是正确的。至于通过它。。。我突然想到，MSDN实际上并没有说

DuplicateHandle

支持

RegOpenUserClassesRoot

或

RegOpenCurrentUser

中的HKEYs。也许这就是问题所在……你所说的“沙盒应用程序”是什么意思？地铁应用程序？使用受限令牌运行的应用程序？什么？@Ben:这有关系吗？虽然从技术上讲AppContainers和手动创建的低IL限制令牌之间存在差异，但我不认为它们会影响这个特定用例。再说一次，我已经遇到了意想不到的行为。沙箱是一个AppContainer（“Metro应用”）。要让它连接到RPC需要一些工作，但除了上面强调的问题外，它现在工作正常。我想你会发现LRPC速度足够快，GUI仍然是瓶颈。即使这种方式没有那么快，我也不认为使用不受支持的技术所带来的麻烦会对性能产生影响。（见鬼，据我们所知，下一版本的Windows 10将明确禁止将句柄复制到沙盒应用程序中。）但是，是的，我猜要么HKCR根本不能复制，要么不能在不同会话之间复制。沙箱似乎是不太可能的原因。