2

I need a process to communicate with a child. No other process should be able to listen in on the communication. So far, I am using socketpair() to create two file descriptors and pass one to the child.

Now I learned that /proc/PID/fd/ exists. It contains a symlink for each file descriptor, with the one created by socketpair() looking like this:

/proc/1402/fd/64 -> socket:[8935]

I didn't find an answer to this, so I want to be sure: Can other processes use this symlink to listen in on the communication?

Edit: To prevent processes from reading memory of other processes, I am using kernel.yama.ptrace_scope. My questions is whether there are other ways in which the information could leak.

Improve this question
2
  • 1
    The traditional Unix security model doesn't protect users against themselves. This includes attaching debuggers such as gdb - and reading memory of processes. Are you sure that your security model is actually sound? Commented Oct 12 at 20:04
  • 4
    What privilege level of attacker are you worried about? Even aside from ptrace, any sufficiently-privileged process could load a driver that can tap sockets or read memory directly without need for ptrace. Anyhow, it probably depends on the socket type; connection-oriented ones probably can't (without kernel privileges) because socketpair creates them already connected and probably doesn't allow multiple connections; connectionless ones (if even supported with socketpair) it would be a race to recv first. Commented Oct 14 at 10:02

1 Answer 1

Reset to default
0

Probably no? But there's some details worth considering...

First of all, /proc/PID/fd/N is generally a convenience and standardization thing -- there are alternatives, though they might be complicated to use. E.g. stuff like pidfd_open() and pidfd_getfd() are direct system calls that overlap in their use case. The point is that the proc filesystem is the messenger, not the message. The security of a given channel comes by securing the channel, not by removing the access tools.

In this specific case, socketpair is typically using UNIX domain sockets (AF_UNIX), so the question of whether or not those can be sniffed is generally independent of the concept of /proc/. Then answer is "maybe" with a heavy helping of "as long as it's allowed" and "as long as you have the right tools."

If you want to dig into that further, have a look at strace, socat, systemtap and perhaps a few others. Also try searching for "sniffing unix domain sockets" or "sniffing AF_UNIX".

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.