[parhamn]

Okay hear me out, I use little snitch for a while. Great product. Love finding out what phones where. I make every single request (except my browser, because I'm fine with their sandbox) block until I approve.

Recently I was wondering how you really have to trust something like little snitch given its a full kernel extension effectively able to MITM your whole network stack.

So I went digging (and asked some agents to deep research), and I couldn't find much interesting about the company or its leadership at all.

All a long way to say, anyone know anything about this company?

[littlesnitch]

Disclaimer: I'm the developer of Little Snitch for Linux. Regarding MITM concerns: The eBPF component, which actually sees all the traffic, is Open Source (GPLv2). You can review it on Github and verify whether it sends any data to user space: https://github.com/obdev/littlesnitch-linux

But the trust issue is still real, the daemon has to run as root because it needs to watch for new mounts and keep a table of file system roots up-to-date, even after loading all the eBPF programs. As a root process, it can technically do whatever it wants. Unless you limit it with a kind of mandatory access control (SELinux or similar).

This is the very first release and we will probably come up with a more restricted permission requirement in the future. For the moment, I try to catch up with bug reports. There seems to be more diversity in the Linux landscape than I had expected.

[hubabuba44]

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

[littlesnitch]

Thanks for sharing! I took rustnet as proof that complex eBPF programs can be done in Rust. Otherwise I would not have dared to try this!

Reducing the set of privileges is on my todo list, but for the moment I just want to get things working without worrying about self-made limitations.

Regarding mount points: I needed the inode numbers of the mounted nodes. With my last commit this requirement has been dropped and it should be sufficient to read mountinfo (and access config files and sqlite3 databases, of course).

I don't need to get the executable from PID, that's already done in eBPF because I need to apply rules based on executable paths.

[hubabuba44]

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.

[ckunte]

Thank you for creating this. I tried running it on Raspberry Pi 5 (running debian trixie), but could not make it work. Does it require compiling in lieu of the .deb file you offer?

[hubabuba44]

Are you referring to rustnet or littlesnitch?

[lapcat]

> All a long way to say, anyone know anything about this company?

Yes, they are indie Mac developers who have been in business for more than 20 years, and Little Snitch for Mac is beloved by many users for a long time.

[umpalumpaaa]

Everything has a price though… (I also use little snitch)

[lapcat]

> Everything has a price though…

What is that supposed to mean in this context?

[gmzamz]

Given sufficient motivation the little snitch dev could essentially supply chain attack every user, or even specific users.

Said motivation could be a nation state handing them $XXX million dollars

[parhamn]

Or even sell the whole org for say $50M and no one ever mentions anything.

I think the type of users it attracts (techies, crypto ppl, etc) makes it worth more too.

[latexr]

Like how it happened for Bartender, another macOS app which required a lot of permissions. It was sold to a company and they told no one, until a user noticed via the now defunct MacUpdater that the app signature changed.

Ben Surtees (Bartender’s original developer) burned all the good will accumulated over years in one moment. Never again can anyone trust software under that name.

[lapcat]

> I think the type of users it attracts (techies, crypto ppl, etc) makes it worth more too.

No, this by itself doesn't make Little Snitch or any business worth $50M. You're dreaming. That's a crazy valuation.

[lapcat]

> Said motivation could be a nation state handing them $XXX million dollars

You're missing the most important part of the motivation here: why in the world would a nation-state give a damn about Little Snitch, especially to the tune of $XXX million dollars?

A nation-state could pay $XXX million to your significant other to spy on you. But again, a nation-state doesn't give a damn about you.

[wafflemaker]

>why in the world would a nation-state give a damn about Little Snitch, especially to the tune of $XXX million dollars?

Per user hacked, it can be very cheap¹ compared to bribing anyone. And give data/access that SO can't get.

State is not interested in you until it does. Being Jewish, Polish, Gypsy, Gay. Or just WrongThinking. Or maybe it becomes super cheap and easy to process all information?

1: it can even be free. You either give us backdoor to all your users or you rot in jail. Here's a complementary beating up or pictures of your kids, to argument our position further.

[chabreck]

its been known for some time that little snitch and other personal firewalls are established targets of three-letter agencies https://news.ycombinator.com/item?id=13813160

[umpalumpaaa]

That’s what i meant. Thanks for reading my mind. :)

[Leptonmaniac]

Well, that is obvious, is it not? It means They are interested in The Plan and have enough power that a vague comment is all you gonna get. Cannot have Them finding out that we are on to Them. Though of course, The Plan already accounts for that, so They already know and will do Something about it. Want facts? Wake up, do your Research!

[ignoramous]

disclaimer: I co-develop (FOSS) Little Snitch / Open Snitch inspired firewall but for Android

> little snitch given its a full kernel extension

On macOS, don't think Little Snitch needs kernel exclaves / extensions. Apple provides userspace ("Network Extension") APIs (however limited) for apps like Little Snitch to use (instead of pf).

> effectively able to MITM your whole network stack

"MITM" means something else, anywho... if network observability (not firewall) is the primary need, cross-platform (GUI) sniffers like Sniffnet exist: https://github.com/GyulyVGC/sniffnet