This is a question for operating system security experts.

We have an application using one platform/language, and it has to integrate with a library that uses another platform/language. There is no acceptable linking technology, and for unrelated reasons, we can't migrate either side to have both in a common platform/language.

The proposed solution is to wrap the library in an executable written in the same language of the library, spawn it from the parent application, and use the standard input and output pipes (stdin/stdout) to communicate.

We also have additional precautions, such as:

  • The executable that links the library is always signed, and the parent application verifies the file signature before spawning the child process.
  • The spawning of child process always uses the absolute path. We bypass the environment PATH variable.
  • The parent and child applications are part of the same build and are always deployed together, and this is validated during handshake.
  • The protocol is binary and we use either fixed-length or length-prefixed data in all encapsulations. If fixed-length, we always ensure full read before processing. If length-prefixed, we always validate the input length against boundaries, before reading variable-length data.
  • The library host executable has no outstanding privilege. It is useless without credentials provided by the caller application. Without those credentials, a malicious actor cannot do anything with the child executable.
  • No process is ever forked.
  • Security precautions are in place for the machine (anti-malware installed, use only approved software, always headless mode, etc).

That said, given the integration is perhaps unusual in the organization's culture, some members of the team are suggesting a microservice instead, with encrypted TLS communication. The microservice approach feels overkill because it would expose endpoints and that requires proper network isolation, certificates, authentication, etc. Not to mention startup and reliability issues (the microservice would have to start independently, would need a watchdog, etc while the child process can start and terminate on-demand by the parent process).

The main point of contention is the use of the stdin and stdout pipes, and the fact that we don't encrypt this communication. To the best of my knowledge:

  • The pipe data resides on a memory buffer that is only visible to the sides of the pipe (parent and child processes). The piped data is never persisted or cloned.
  • Operating systems never automatically log or make it easy for administrators to capture pipe communication between two processes. There is not even a Linux or Windows configuration for that, and any tool would require administrative or kernel privileges, like a debugger.

Are those assumptions correct? I would like to learn from operating system experts if stdin and stdout traffic data between two processes is also deemed as sensitive as other forms of shared memory such as memory-mapped files, Unix domain sockets or Windows named pipes, in the sense that it's always well protected from other actors in the machine.

1 Answer 1


Pipes are a local form of communication. It would make no sense to encrypt them. Anything that can spy on traffic on a pipe could also spy on the processes themselves.

Anonymous pipes are pretty safe in that there's very little risk of misconfiguring them. Unlike named pipes, named sockets or network sockets, there's no external entry point (directory entry or network port) that you have to protect through permissions or firewalling. The only risk with an anonymous pipe is if your programs run an external programs: make sure you set the close-on-exec flag and you'll be good. (You say “No process is ever forked” but that's not something you can fully count on: a library that you use might fork a process for its own purposes.)

Switching from pipes to network sockets with TLS would only make sense if you want to be able to run the two processes on different machines. This would reduce the security of the communication, so you'd need TLS's protection to compensate. It could increase the security of the processing, since a compromise of one half would not directly compromise the other half, but this is clearly not something you need since you'd be prepared to run everything in the same process if it was possible.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .