I wish to use named pipes in my app. Server would be NT service and client is user space app.
I presume that there could be a problem if someone could create application client that lock pipe(or something) and my server stop receive messages.
I wish to add that client should always send messages and server receive them. If someone disturb that process there be a problem.
I need advice how to secure named pipes
Here are some things to consider in terms of implementing "secured" named pipes.
Named pipes in Windows OS are placed in a special path \\.\pipe\ to which every user (including guest) has access.
A named pipe can have multiple instances that share the same name;
Each instance connects exactly one pipe server and one pipe client.
New pipe clients connected to the pipe servers in round-robin order.
The creator of the first instance decides the maximum number of instances as well as specifies the security descriptors.
This includes an access control list (DACL) to control all the instances.
The default descriptor grants read access to everyone and full access only to the creator user and the administrators.
If a named pipe does not exist, any user can create the first instance and set DACL of all pipe instances.
If it exists, only users with FILE_CREATE_PIPE_INSTANCE permission can create new instances.
Take advantage of FILE_FLAG_FIRST_PIPE_INSTANCE flag for your server to ensure that it is creating the first instance.
Credits: Man-in-the-Machine (MitMa) attacks on ill-secured inter process communications, which explains the harm of not securing many IPC methods including named pipes.
AFAIK, multiple different client processes can all open the named pipe and write to the single reader process. This would certainly hold true on Unix, so it probably does on Windows too.
That means that a single process cannot stop other processes writing to the server - though a misbehaved process might overwhelm the server with its messages. There is no easy protection against an over-enthusiastic client.
Related
What I want to do is create a named pipe server that routes messages between connected peers. On Windows it seems that you first have to create a pipe and then connect it to a client and then you read from the connected client pipe to get the message you want and then that handle is bound to that client and you have to create a new named pipe. Is there no way to easily multiplex all the clients into one handle so I don't have to read from each client separately? To write to the clients from the server you obviously have to use the clients’ handle. Maybe the server can close the connection every time it has processed a request but that seems a bit unnecessarily wasteful. I would rather avoid implementing my own named pipes with shared memory...
"you first have to create a pipe and then connect it to a client"
Not exactly. The server process creates the pipe, but the client connects itself. Also, the client can try to connect and block if the server hasn't yet created the pipe.
"you read from the connected client pipe to get the message you want and then that handle is bound to that client". True. Doesn't stop you from immediately waiting for the next client.
"Is there no way to easily multiplex all the clients into one handle?". No, that would defeat the point of the HANDLE. That's the bit you need to demultiplex the clients.
What you seem to miss is that you can set the number of pipe instances to PIPE_UNLIMITED_INSTANCES, and read all of them using a shared LPOVERLAPPED_COMPLETION_ROUTINE callback. The callback will tell you which HANDLE and thus which pipe has data available.
I am working on app (c++) that consist from two parts.
Control Panel working under restricted user account (with UAC enabled)
Windows Service, performing some useful tasks
I need to collect user preferences in control panel and send them to service.
What is the best method for sending/receiving data from control panel to service?
The sockets and named pipes are good, but they may cause windows firewall to show security warnings.
Shared memory also is good, but it requires a lot of synchronization between sending and receiving threads.
Is there any other method that I can use?
Thanks,
Khachatur
Shared memory requires three extra mutex objects on each side. Not so much. If you don't want to write anything, our MsgConnect (open-source) implements MMF transport and has a sample of communicating between the service and the UI application.
I have a system where I want to listen to a socket and wait to client connect and then pass the connection to another application that I'll start as soon as the connection is established.
I do not have control on this other application and can only set the port where it will listen, but I want to have one process for each new client.
This is what I'm trying to do:
I've been searching for a solution, but I thing I don't have the right terminology, but I managed to find on Richard Stevens' "Unix Network Programming" something about the AF_ROUTE family of sockets that may be combined with a SOCK_RAW to route a connection to another IP and port. But there's too little documentation about how to use this flag and seems to require superuser privileges (that I want to avoid).
Maybe there's an easier solution but I'm probably using the wrong terms. Is it clear what I want to do?
I don't think you'll be able to just "pass" the socket like you want to, especially if you can't change and recompile "APP". Sockets include various administrative overhead (resource management, etc) that are linked to the process they are owned by. In addition, if you can't recompile APP, there is no way to make it bypass the steps involved with accepting a connection and simple have an already open connected "handed" to it by your router.
However, have you considered simply using router as a pass-through? Basically, have your "Router" process connect via sockets to the each "APP" process it spawns, and simply echo whatever it recieves from the appropriate client to the appropriate APP, and visa versa for APP to client?
This does add overhead, and you will have to manage a small mapping to keep track of which clients go to which apps, but it might work (assuming the APP or client aren't basing any behavior off of the IP address they are connected to, etc). Assuming you can't recompile APP, there might not be too many other options.
The code for this is relatively simple. Your handler for data recieved from APP just looks up the socket for the appropriate app from your mapping, and then does a non blocking send of this data out on it. Likewise the handler for data recieved from client. Depending on how exactly the clients and app behave, you may have to handle a bit of synchronization (if you recieve from both simultaneously).
I am looking forward for an example for using a user defined control code in services. I want to send a user defined command to my windows service. At this command windows service will create a named-pipe for client process, and client will establish a connection with this named-pipe by CreateFile function. My custom control sometimes works well but later it shows error for invalidation.
So how can I establish information exchange between a service and various clients?
SERVICE_USER_DEFINED_CONTROL is rarely used. When it is used, it is generally to prompt the service to re-read its configuration file. (On unix SIGHUP is generally used for the same purpose).
In your case the correct answer is to simply create the named pipe on startup and keep listening, and wait for someone to connect if they ever do.
We create app A. start it from super user. It opens socket and waits for connections. Connection establishes. We want to let another, not forked, separately launched by super user process to take that established connection and be capable to send data over it not interrupting/reestablishing it. We create both A and B apps and we can implement any required logical algorithms into them both. How shall our apps logic look like? and will Ancillary library be capable to help me with such task?
You can open a unix domain socket between the processes and pass file descriptors over it. See this site for an explanation and example:
http://www.lst.de/~okir/blackhats/node121.html