Hacker News Reader

Comment by buzzdenver | Hacker News Reader

How robust is it to rely on the user mode program to look at /proc? Do you ever get timing issues when the process already exited or its PID was recycled?

Also this part is incorrect/confusing: "When I ran ps aux | grep kafka, I saw that the kafka process ID is 311738", since the screen grab underneath shows a "tail -f" process.

View on HN

It's not robust at all. Programs can and will exit before the userspace daemon is able to read from /proc. Malicious programs can even attribute their network activity to any program on the system they are able to exec by execing that program immediately afterwards or concurrently from another thread. One can properly track program paths/arguments by setting kprobes on the exec functions within the kernel and copying the data to a ring buffer read in userspace or by reading out of the task struct using bpf_probe_read_kernel.

> Programs can and will exit before the userspace daemon is able to read from /proc that's depend on the use case, and we are mainly tracking server which are not terminated during our runtime. of course if we are tracking "not servers" (like curl) it can happen, and for that you can find other fallbacks. regardless, we cannot assume we will be existing before all other server and client have started running, so we are trying to do "best effort", that's why counting on hooking the `exec` syscalls is not robust either.

If best effort is good enough and your use case doesn't require robustness, reading out of host /proc certainly works. Tracking execs with hooks in the kernel's internal exec mechanism with a separate indexing step at startup is worth the extra effort for use cases that do require accurate data, such as security observability.

first of all, thanks for the ps aux mistake, I fixed it (the correct entry point is `tiny -- /run.sh`)

regarding the question, it depends on the use case, I'm mainly tracking servers which are not terminated therefore it works good enough for me but of course if I'm capturing clients (for example curl) it might be problematic for such use-cases we have additional fallbacks, adding the kernel comm task along with the PID, or to hook `execv` and `fork` to have more time before the process is being terminated

> since the screen grab underneath shows a "tail -f" process

Oops..

Reply on news.ycombinator.com