One of the most annoying programming challenges I've ever faced 🤦‍♂️

[GyulyVGC]

In today's blog post, I went through the challenges and implementation details behind #170: supporting process identification in Sniffnet.

If implementing this feature seems like a no-brainer to you, well… read the post because it turned out to be a much more complex task than I could imagine, and this is the reason why the related GitHub issue has been open for almost 3 years.

[vlabo]

I work on a closed source project that has the same requirement. I agree the problem is hard but getting the PID is the simpler part.
The requirement for us is that connection should not be missed so even very short lived connection need to be accounted for,
the hard part is to make the connection stay alive while you collect all the necessary data.

So for example, curl is called few packets are send and shortly after the server response and the process is killed. The windows where the proc file needs to be read is very short and if the connection is not "paused" you may end up with invalid PID, since both windows and linux can reuse PIDs it can even read the wrong proc if you dont account for that edge case.

You probably already know that but Portmaster has a reliable process -> connection detection on windows and linux.

I believe that the eBPF part is easy to implement and will not make sniffnet "heavy" or hart to install. And since the linux is doing heavy validation during the JIT complication it will not crash the kernel. (This does not solve the short process problem by itself)
https://github.com/safing/portmaster/blob/development/service/firewall/interception/ebpf/programs/monitor.c

[GyulyVGC]

Interesting.

I'm curious though: forcing a connection to stay alive longer than needed can decrease performance I guess, is this the case?
For example for such protocols (if any) that require the previous connection to be closed before starting a new one.
Or more in general just OS overhead in keeping more processes open, even if for very short periods.

[vlabo]

There is small performance overhead but the time is counted in tens of milliseconds, so unless measured it will not be noticeable. Unless the user has weird uses case with thousands of small connections.

Our tool is a firewall and small overhead is expected and the overhead is only in the first packet until the verdict for the connection is decided.

Im not aware of protocols that require previous connection to be closed before starting a new one. Do you know of any?

[GyulyVGC]

I'm not aware of specific protocols, but I can imagine cases where the remote has some logic checks of this sort, independently from the used protocol.

But I understand that being your product a firewall you need way more accuracy than a monitoring tool.

And by the way the reason I'm a bit reluctant to use eBPF is that it requires admin privileges to run and that it could be not compatible with older kernels or specific Linux versions.
At least these were my findings when I was playing around with oryx.