WCF命名管道的安全性问题 [英] WCF security problems with named pipes

问题描述

我有一个稍微复杂的设置，当然，它在XP中可以正常工作，但在Windows 7上却令人窒息.这似乎很疯狂，但在当时还是有道理的！

I have a slightly complicated setup that, of course, works fine in XP, but chokes on Windows 7. It may seem like madness, but it made sense at the time!

我有一个WPF应用程序，它可以启动，然后启动另一个与外部设备通信的应用程序.启动后，它将通过命名管道(net.pipe)使用WCF(由新进程托管)与新进程建立通信.这似乎在任何一个OS上都可以正常工作.

I have a WPF application that launches and then launches another application that communicates with an external device. After launching it establishes communications with the new process using WCF (hosted by the new process) via a named pipe (net.pipe). This seems to work fine on either OS.

我想将WPF应用程序的某些功能从外部提供给命令行程序，因此我设置了另一个WCF服务，这次由WPF应用程序托管，并再次通过命名管道公开它.同样，这似乎可行.

I wanted to make some of the functionality of the WPF application externally available to a command line program, so I set up another WCF service, this time hosted by the WPF application and again exposed it via named pipes. Again, this seems to work.

接下来，我想通过网络提供WPF应用程序的功能.现在，很重要的一点是WPF应用程序可以从常规用户帐户运行，因此我认为在Windows 7上进行此工作的最佳方法是创建一个Windows服务，该服务将提供Web服务部分并将其通信回通过相同的命名管道的WPF应用程序在命令行上可以正常工作.我实现了这一点，它在XP上运行良好，但在Windows 7上却阻塞了.问题似乎与试图在Windows服务和WPF应用程序之间建立命名管道连接有关.

Next, I wanted to make the functionality of the WPF application available via the web. Now, it's important that the WPF application be runnable from a regular user account, so I thought the best way to make this work on Windows 7 would be to create a windows service that would provide the web service part and have it communicate back to the WPF application via the same named pipe that works fine for the command line. I implemented this and it runs fine on XP, but it chokes on Windows 7. The problem seems to be with trying to establish the named pipe connection between the windows service and the WPF application.

如果我以管理员身份运行WPF应用程序，则可以正常运行.因此，运行Windows服务的帐户似乎无法与通过命名管道托管WCF服务的常规用户帐户进行通信.有没有办法使这项工作?似乎以常规用户帐户运行的WCF服务可以使用命名管道与同一个帐户中运行的另一个应用程序进行通信，但是似乎无法使用不同的帐户来执行相同的操作.

If I run the WPF app as an administrator, it works fine. So it seems to be a problem with the account that the windows service is running in can't communicate with a regular user account that is hosting the WCF service via named pipes. Is there a way to make this work? It seems a WCF service running in a regular user account can communicate using named pipes to another app running in the same account, but it seems it can't do the same thing with a different account.

奇怪的是，相反的方法似乎起作用.实际上，Windows服务确实还会公开带有命名管道绑定的服务(由于该服务一直在运行，因此它被用作激活功能).我可以从WPF应用程序连接到该服务，而不会出现任何问题.

Oddly, the reverse seems to work. The windows service does, in fact, also expose a service with a named pipe binding (it's used as an activation function since the service is running all the time). I can connect from the WPF app to this service without any problems.

我对安全性的了解有限.有人可以照亮发生了什么事吗?

My knowledge of security is somewhat limited. Can anybody shine a light on what's going on?

推荐答案

这个问题以前在SO上已经问过好几次了.例如，请参见通过命名管道从Windows服务连接到桌面应用程序

This question has been asked several times previously on SO. For example, see Connecting via named pipe from windows service to desktop app

问题是您的用户会话应用程序不具备必要的SeCreateGlobalPrivilege安全特权，该安全特权使他们无法在其他会话可见的全局内核名称空间中创建对象，而只能在仅在会话中可见的本地名称空间中创建对象.另一方面，默认情况下使用此特权运行的服务可以这样做.

The problem is that your user session applications don't possess the SeCreateGlobalPrivilege security privilege necessary to allow them to create objects in the global kernel namespace visible to other sessions, but only in the local namespace which is only visible within the session. Services, on the other hand, which run with this privilege by default, can do so.

不是以此方式约束到本地名称空间的命名管道对象本身，而是另一个命名内核对象，即共享内存部分，WCF命名管道绑定赖以将其实际发布到其客户端的对象管道的名称，它是一个GUID，每次启动服务时都会更改.

It is not the named pipe object itself which is constrained to the local namespace in this way, but another named kernel object, a shared memory section, on which the WCF named pipe binding relies in order to publish to its clients the actual name of the pipe, which is a GUID which changes each time the service is started.

您可以通过反转角色来克服此限制-将Windows服务应用程序设置为用户会话应用程序连接到的WCF服务. Windows服务将其服务发布到您的会话没有问题.由于Windows服务始终在运行，而会话及其应用程序随您登录和注销而来去去，因此以这种方式进行连接更有意义.您将需要使用双工合同来定义服务，以便在建立连接后，通过WCF服务进行的基本通信流仍然可以按照您原本打算的方向进行.

You can get round this constraint by reversing the roles - make the windows service application the WCF Service, to which your user session apps connect. The windows service has no problem publishing its service to your session. And connecting things up this way round makes more sense because the windows service is always running, whereas your session and its apps comes and goes as you log in and out. You'll want to define the service with a duplex contract, so that once the connection is established, the essential flow of communication over the WCF service can still happen in the same direction you originally intended.

这篇关于WCF命名管道的安全性问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！