C 限制进程对管道的访问（Windows）

是否可以按进程限制对命名管道的访问（映像名或进程ID都可以）

这里的上下文是一个过滤器微型驱动程序，它必须与执行大部分业务逻辑的用户空间服务通信。由于这种通信是安全敏感的，我想保护它不受外部干扰，而默认情况下，驱动程序创建的命名管道似乎可以通过任何知道管道名称的用户空间进程进行通信（通过静态或动态分析发现这一点很简单）

这是我已经知道的：管道是Windows中的安全对象，因此，它们有一个安全描述符。这个安全描述符可以包含一个DACL，它应该限制对对象的访问。我已经广泛地搜索了条件ACE的文档和示例，我希望这些文档和示例能够满足我的需求，但我没有找到任何相关的内容

---

编辑：我已接受MSalters的回答。人们普遍认为，

SYSTEM

==

ring0

，虽然司机的代码签名似乎很重要，

SYSTEM

可以轻松禁用代码签名，因此不需要将权限从

SYSTEM

升级到

ring0

——它们已经相同了。另一方面，即使是默认的安全描述符（在minifilter驱动程序上下文中-请参见

FltBuildDefaultSecurityDescriptor

）也包含一个限制，因此只有

系统

和管理员可以访问该对象，因此无需（或可能）采取进一步的操作。

图像名称仍然不安全，任何人都可以创建“Notepad.EXE”。进程ID只是一个数字，可以重用，因此也没有保护。此外，有许多方法可以将DLL偷偷带到另一个进程中，因此即使您知道某个进程正在运行您的EXE，您仍然不知道它是否只运行您的EXE

---

Windows安全模型使用安全主体（用户和系统帐户）的概念。这些是ACL直接支持的，并且可以防止欺骗。如果您的筛选器驱动程序拒绝与任何人交谈，但它愿意与用户X的进程A交谈，它应该愿意与用户X的任何进程交谈，这是有道理的。

我知道这是Windows安全模型，但是完整的映像名（以及路径）对我来说是可靠的，因为涉及到筛选器驱动程序，它可以监视服务二进制文件不是修改器。此外，由于双方之间通信的高度安全重要性，如果我不保护此管道，它将间接允许从系统升级到ring0，这在我的情况下是不可接受的。当然，我欢迎对我的“安全模型”和假设的任何批评。我还应该补充一点，计划中还有其他安全措施，例如要求人工用户检查哪些Windows用户可以调试进程等等，这些措施旨在进一步限制其他攻击向量，与您指出的类似，我不知道过滤器驱动程序（在单个设备级别）如何确定某个完整路径（通常是系统范围的）是可靠的。即使文件本身在磁盘上没有更改，您也必须确保完整路径不完全指向其他设备。虽然你可能认为C:\是你的硬盘，有重分析点之类的东西，但这并不是那么简单。至于“从系统升级到环0”，我将给陈雷蒙频道：一旦你控制了系统，你就控制了系统。作为系统，您已经可以加载另一个驱动程序，这意味着无论您在驱动程序中做了什么，系统都可以访问环0。您是正确的。我刚刚意识到，当您在系统中运行时，您可以启用未签名的驱动程序，并从中运行您想要的任何代码作为ring0。我接受答案。