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.
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.
There is currently no treatment of errors because I would not know how to handle them anyway. There are two tables which can overflow affecting the filter: the table of open flows and the table of recent DNS lookups. The table of flows just fills up, meaning that we cannot store state about new flows. Without state, we can't attribute a process to them and end up evaluating rules on each packet. I guess that blocklists would still work, but more specific rules would not be applied (and the default decision would be taken, whatever you have configured).
The DNS lookups, on the other hand, are LRU. If the table overflows too soon, we won't be able to derive names for IP addresses and name-based rules would fail.
gotcha... makes total sense. LRU for the DNS map is definitely the right call for a desktop setup. and falling back to the user's default policy is smart so you don't randomly brick their internet if an app goes crazy.
really appreciate the honest answer, man. awesome work on this...!
On macOS, it requires access to /dev/bpf. That's why we added filter rules for bpf there.
On Linux, we intercept at a level where packets already have an Ethernet header. I hope that Paqet injects before* this layer, but only a test can give the proof.
Thanks for the response. Sorry I should of been less vague. Paqet works on raw sockets with KCP. Though it's intended for good. What's to assume bad actors aren't also using this method to get around solutions like littlesnitch?
A recent example, but not the only is a Iran a botnet, using this to get around detection.
eBPF is very limited in the code complexity you can achieve. DPI on QUIC, for example, needs a lot of cryptography. That's simply not possible in eBPF. DPI on ordinary TLS still requires that you collect enough network packets to get the name, hold them back until you have a decision and then re-inject them. Holding back packets is not even possible at the layer where we intercept. And even if we find a layer to do this, it adds enough complexity that we no longer pass the verifier.
As the author of Little Snitch for Linux, I can tell you what drives us: we are a small company where people (not investors) make the decisions. It was a personal choice of mine, driven by a gut feeling. I'm curious about the outcome...
The Wikipedia page for Little Snitch indicates that it's written in Objective-C. Is that still the case? Before going with the new implementation, did you attempt (or consider) to port the current codebase (using e.g. Cocotron or GNUStep libraries)? If so, how good or bad of an experience was that?
Why is Little Snitch for Linux™ so hard to find from the company homepage[1] and the product page from the legacy app[2]?
Did the fact that you knew it was going to be made partially open source factor into your decision to develop a new, JS-and-DOM-based UI rather than having build targets for a shared, cross-platform codebase? (E.g. so that you wouldn't end up disclosing the source for the proprietary Mac version?)
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.
> I decided for the minified version because it's smaller. That's the purpose of minification, after all.
Mm... the purpose of minification, when it's not (also) being used for obfuscation purposes, is tied directly to the execution model of Web apps—constraints that don't apply for desktop applications (even if they are implemented in e.g. the same programming language or using the same or a similar runtime).
App makers and browser extension developers who shoehorn all of the (frankly already very bad or at least questionable) "best practices" associated with the tooling that was created to deal with creating/maintaining/delivering SPAs and other browser-based products into applications loaded from disk are just fundamentally not thinking things through.
For a security-sensitive application like this one, where a show of nothing-up-the-sleeve is only a benefit, one should expect there to be _no_ minified blobs in use.
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.
As a paying customer, I wasn't expecting this so thank you! Can you expand more on your gut feeling? Also, I have different security expectations on Linux vs MacOS. Would you ever consider open sourcing the daemon?
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.
reply