Improvements to process attribution

[ckuethe]

[2017-04-20 13:08:55,017] (WARNING) Could not find process for udp connection 172.18.115.120:123 -> 91.189.91.157:123
[2017-04-20 13:08:55,017] (WARNING) Could not detect process for connection.
[2017-04-20 13:08:55,044] (WARNING) Could not find process for tcp connection 172.18.115.120:38052 -> 216.58.192.14:80
[2017-04-20 13:08:55,045] (WARNING) Could not detect process for connection.
[2017-04-20 13:08:55,105] (WARNING) Could not find process for udp connection 172.18.115.120:52695 -> 239.255.255.250:1900
[2017-04-20 13:08:55,105] (WARNING) Could not detect process for connection.

Seems like additional ways of linking a packet to a process should be investigated.

[evilsocket]

This is basically a subset problem of #12

[ckuethe]

I disagree. This is not about figuring out what the process is called once we have its pid, it's about the fact that we're unable to associate traffic to ntpd or avahi (or some other long-running process) in the first place.

[evilsocket]

What I meant is that if we find another way of collecting connection info such as the process name, that would ideally fix this issue as well.

[ckuethe]

Pid is the canonical identifier of a process. There are connections that cannot be attributed to a process, and I see no progress toward additional techniques for establishing this link.

#12 is more about UI/UX. Reliability of attribution aside, when process 12345 wants to connect to the network what can we tell the user about that process to help them make a decision about whether or not to allow that connection.

[evilsocket]

Oh man, I miss the good old times when people just trusted the developers and didn't need to try to teach them OS basics in order to prove their point.

Since my previous comment was apparently not clear enough, let me rephrase.

It is clear that just relying on the /proc filesystem in order to get information about a connection, a process or whatever is involved in this project, is definitely not reliable and not enough.
Considering that a more robust approach is required, for instance a custom kernel module, this solution would also be able to keep track of processless connections, just like the ones you mentioned, and will expose a connection-type-agnostic interface to the user land ( can be something in /dev that we query using ioctls, or whatever ) that eventually will replace the current routines that rely on /proc.

Giving that I like to fix things once and fix them for good, the aforementioned solution will solve both issues, that's why I closed this one, just to keep the conversation on the more technical thread.

Is this enough for you or do we want to keep talking about how operating systems work? :D