Secure IPC method for C++ in Linux

Question

I just can't choose a method of interprocess communication that would fit my goals, so I ask for help. My list of needs is as follows:

1. It must be safe. Communication should not be hacked. Communication will only take place between two processes. There should be no possibility of a MITM attack. The source code of the program must remain open
2. This method should work on Linux. I don't need the method to support any other platform.
3. Suitable for C ++
4. Bidirectional
5. Minimum delay
6. I'm not entirely sure about the amount of data transferred. Most likely, the volume will not exceed the size of char[32].

This is the first time I needed to implement IPC. I am lost among all the possible methods for IPC. I cannot provide any significant research. Although I have already written 3 simple examples for shared memory, socket and pipe, I cannot find a way to ensure that communication is not hacked. Is it possible at all to be sure of this?

Absolutely any solution is suitable, the main thing is that the first three points are fulfilled.

• gnat: Sharing your research helps everyone. Tell us what you've tried and why it didn't meet your needs. This demonstrates that you've taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask
• Andrew Henle: It must be safe. Communication should not be hacked. Communication will only take place between two processes. There should be no possibility of a MITM attack. Good luck with all that. If that were possible, there'd be no such thing as hacking or MITM attacks. The security of your two processes and the communication between them is never going to be better than the security of the operating system you're running on.
• Philip Kendall: "Communication should not be hacked." What's your threat model?
• Stack Exchange Broke The Law: How do you identify the correct program to communicate with? What if the user has modified their copy of the program? Does it still count as the same program?
• Stack Exchange Broke The Law: @Dines Then you can put a UNIX socket in a location that only root can write to. Note that a user may want to run their own separate copy of the program, so they should have an option to change the socket location.

Answer 1

If you're rolling your own IPC you're already going down the wrong path. How much time will you spend coming up with an inadequate, buggy, insecure version of something other teams of people have already built? Be smart: Choose an existing open source IPC library that is already working, debugged, high performance, and high security.

For example, gRPC, which supports SSL/TLS out of the box, and has great C++ bindings.

gRPC is fine, even great: lots of people use it with no problems (security or otherwise). But this isn't a recommendation for you. I suggest: Look around, there are a number of such libraries, pick the one that you really like.

P.S. For IPC between two processes on the same machine gRPC has an inproc transport ability built-in that's more efficient than going over HTTP on the same machine. You'll have to search for docs on it because it isn't well documented, but it's there. And, since it will use methods like Unix sockets or pipes or something like that it'll be very secure.

• Dines: So I realized that I didn't understand anything. How can I use gRPC to be sure that an attacker will not launch the second version of the server and thereby not intercept communication? Or intercept handshake. Or something like that? If gRPC is not a recommendation then maybe you know a more native IPC method for GNU / Linux? So far I am trying to find a way to communicate safely inside D-Bus.
• davidbak: It'll be as secure as anything else on Unix/Linux - if you use it correctly. Secure if and only if using it correctly: That'll be true of anything you do. Secure as anything else on Unix/Linux: If that already isn't secure enough for you then you're in trouble because you can't do better than that (and stay on Unix/Linux).