hubabuba44

Isn't the problem that without exploration we won't actually get new goals e.g. can AI come up with new math conjectures instead of "just" solving existing ones.

Ah nice, I'll take a look at the open source eBPF part for the process resolution which is an area where I still have some rough edges and there is probably something I can learn from your approach.

Are you referring to rustnet or littlesnitch?

I'm genuinely curious why this is flagged?

I'm happy to see this on Linux and I really appreciate the open-sourcing of the eBPF component.

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).

Congrats on the Linux port, this looks very nice.

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.

It looks very slick!

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.

Thanks, I see. From the title I didn't infer that it's browser or openssh specific but that's ok.

Ok, if you say so

Why doesn't it mention landlock?

I'm working on rustnet (https://github.com/domcyrus/rustnet) which is a cross-platform network monitoring TUI built with Rust that provides real-time visibility into network connections with deep packet inspection.

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

Thank you very much!

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

Looks like this tech is a bit brittle.

To me it looks too chaotic to be a planned privatization plan but who knows.

We will see. I understand that money shouldn't be an issue but trust might be, no?

Cool thanks!

I assume that this comment should go somewhere else or I'm not able to decipher the message ;)

The real irony here is that a lot of ycombinator founders and the people reading HN were exactly the ones making this possible and now start to wonder why the snake eats its own tail.

If the initial tcp 3 way handshake fails it can be quite a bit longer you would have to wait than a few ms. Depending on OS it is a second or more.