I maintain rustnet, a passive network monitor in the same eBPF + libpcap space, so I ran into a lot of the same issues. Wanted to share what has been working for me on the privilege side, in case any of it is useful for v2.

rustnet ships with setcap 'cap_net_raw,cap_bpf,cap_perfmon+eip' instead of setuid-root. During startup it loads the eBPF programs, opens the pcap handle, and then drops all three caps before touching any packet data. It clears the ambient set, sets PR_SET_NO_NEW_PRIVS, and applies a Landlock ruleset that restricts the filesystem to /proc plus configured log paths and blocks TCP bind/connect on 6.4+ kernels. Code is in src/network/platform/linux/sandbox/ if you want to have a look.

On the "needs to watch mounts" point, totally fair that Little Snitch needs live mount visibility, but I think it is achievable without staying UID 0:

- Watching for mount changes: poll() on /proc/self/mountinfo with POLLPRI wakes on every mount table change from a completely unprivileged process (this is what systemd and mount(8) use internally). Alternatively, an eBPF program on the mount/umount/move_mount tracepoints can be loaded at init and stream events via a ring buffer, with no continued cap cost after load. - Resolving an arbitrary PID to its binary across container mount namespaces: CAP_SYS_PTRACE is enough for that. The /proc/PID/root magic symlink does the namespace translation inline inside the kernel pathwalk, so open("/proc/12345/root/usr/bin/firefox", ...) opens the right file in the right container's view without ever calling setns(), which is what would otherwise need CAP_SYS_ADMIN (the new root).

Shameless plug: for anyone who wants something fully open source and terminal-based, I maintain RustNet (https://github.com/domcyrus/rustnet). It's a bit different because it's a TUI for real-time connection monitoring with deep packet inspection, not a firewall. No blocking/rules, but it's cross-platform (Linux/macOS/Windows), the entire codebase is open, and it sandboxes itself after init via Landlock with capability dropping.

Cool to see more network tools for macOS.

For anyone who does prefer a CLI-based approach, I maintain RustNet https://github.com/domcyrus/rustnet which is open source and cross-platform (Linux, macOS, Windows) with real-time connection monitoring, deep packet inspection, process identification, and a terminal UI. Obviously a different kind of tool than a polished GUI app like this, but if you live in the terminal or want something you can script and automate, it might be worth a look.

On the macOS network tools side, have you looked into PKTAP? I use it in RustNet to get process-level attribution for network connections. Might be worth exploring if you want to tie traffic back to specific processes.

Currently I'm spending numerous hours trying to package for multiple Linux distributions. I have to say that building for Ubuntu using the Debian build system and Launchpad seems like a way to spend days for nothing except frustration :) Maybe the problem is also me / PEBKAC

There is no analytics function yet, but if you'd like, please open an issue or PR, I would very much appreciate that.

What may make it interesting:

• Deep packet inspection for HTTP, HTTPS/TLS (with SNI), DNS, and QUIC protocol detection

• Process identification using eBPF on Linux (experimental) and PKTAP on macOS which does also catch short-lived processes that polling procfs or lsof would miss

• Multi-threaded packet processing with lock-free data structures for the UI

• Cross-platform (Linux, macOS, Windows but process identification so far only on Linux/macOS)

The eBPF implementation was a bit more tricky to implement than using PKTAP, but it was very interesting to learn about how to hook into tcp_connect, udp_sendmsg, etc. in order to catch process info before connections disappear.

I built this as a lightweight Wireshark alternative for quick TUI based network inspection with process identification.

Install: cargo build --release, run with sudo or set capabilities. Homebrew tap also available.

Would love feedback on the project and any ideas for additional protocol detection or any other suggestions. Thanks

Comments URL: https://news.ycombinator.com/item?id=45303439

Points: 5

# Comments: 2