littlesnitch

The eBPF filter in Linux Snitch decides immediately, so no TCP handshake leaks. But, as a consequence, we cannot inspect packet headers to verify the remote name and it's easier to trick it to show a false name. Little Snitch for Linux is not a security tool.

What exactly do you mean with rDNS resolver?

We do not want the reverse lookup name. For instance, if you look up a google.com name with dig, you get an IP address. If you then do the reverse lookup with dig -x, you get a 1e100.net name. That's as good as the IP address for our purpose.

Plus: We need to respond with a DROP or ALLOW verdict to a network packet without the ability to do any blocking requests. So we can only use information already available in the kernel to decide.

Yes. For these cases it won't work. OpenSnitch intercepts the client side library for this reason. I would rather want to avoid this for the moment and wait for feedback.

Thanks for that hint! We still get the lookup if it leaves the machine unencrypted, but if you have both, the Unix domain socket and DNS encryption, we miss lookups.

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.

It's hard to expand on the gut feeling. I wanted to have the app myself. Adding licensing to the code, limiting functionality for a demo mode, and then wait whether Linux users would pay for it just did not feel right.

Regarding daemon open source: The future is hard to predict, even more with AI being just invented. I would love to make it open source, but if you can feed it into Claude and tell it to convert it to a Mac version, we could lose our income.

For the moment, we prefer to keep it closed because we cannot estimate the consequences of making it open source.

Sorry, I overlooked that. I actually checked the license only to the point whether we can include it without other obligations and then downloaded what was offered as a download on either the web site or github, can't remember. I decided for the minified version because it's smaller. That's the purpose of minification, after all.

It's somewhat strange that they require the license to be reproduced in every copy, but then offer a download without it. But anyway, I'll prepend the license to the next public release.

Thanks for pointing that out!

I'll post in our blog about the development background later. The Linux version shares no code with the Mac version. Only concepts. It's written in Rust and JavaScript (for the Web UI).

Our site is primarily aimed at Mac users, and most visitors skim rather than read carefully. If the Linux package were more prominent, Mac users would likely click it, struggle to install it, and blame us for the confusion.

And regarding your third question: No. The decision was made when I wanted to run it on our headless servers.

It won't work with WSL because WSL does not provide eBPF, as far as I know.

I'll investigate how much effort it is to adapt the build procedure. But I think this should be possible. I've put an item on the todo list.

Little Snitch for Linux is not made to defend against malware. You need to code with paranoia in mind from the very beginning if you want that.

We meanwhile found out that it does not pass the eBPF verifier on kernels above 6.19.0. When this happens, it's restarted over and over again, running the eBPF verifier in a loop on all available CPUs.

We are working on the issue.

It depends on several factors. One factor here was the decision to make it web based. The other is that this one is by me, and I'm not a UI designer or frontend developer. I usually work on network stack, model design and other low level stuff. Exactly the same as most Linux developers, so it's no surprise that the outcome is similar.

As far as I can tell, they are very different in their goals. Portmaster is targeted at security and business customers, it's surprisingly powerful for an open source project. The interception mechanism seems to be based on iptables, but I skimmed over the source code only quickly.

Little Snitch for Linux, on the other hand, is much less complex and tries to analyze and filter based on DNS names, not IP addresses where possible. It is not made for security, but rather to provide insight for the curious what's going on. It hooks into the kernel via eBPF, not iptables.

An external appliance does not have access to your process table, so it can't tell you which process originated the request. Only which device.