Hacker News: littlesnitch

New comment by littlesnitch in "LittleSnitch for Linux"

littlesnitch — Fri, 10 Apr 2026 12:15:08 +0000

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.

New comment by littlesnitch in "LittleSnitch for Linux"

littlesnitch — Fri, 10 Apr 2026 12:08:03 +0000

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.

New comment by littlesnitch in "LittleSnitch for Linux"

littlesnitch — Fri, 10 Apr 2026 12:01:24 +0000

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.

New comment by littlesnitch in "LittleSnitch for Linux"

littlesnitch — Fri, 10 Apr 2026 11:59:09 +0000

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.

New comment by littlesnitch in "LittleSnitch for Linux"

littlesnitch — Fri, 10 Apr 2026 11:54:50 +0000

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.

New comment by littlesnitch in "LittleSnitch for Linux"

littlesnitch — Fri, 10 Apr 2026 11:44:26 +0000

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.

New comment by littlesnitch in "LittleSnitch for Linux"

littlesnitch — Fri, 10 Apr 2026 11:31:16 +0000

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!

New comment by littlesnitch in "LittleSnitch for Linux"

littlesnitch — Fri, 10 Apr 2026 11:24:54 +0000

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.

New comment by littlesnitch in "LittleSnitch for Linux"

littlesnitch — Fri, 10 Apr 2026 11:09:49 +0000

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

New comment by littlesnitch in "LittleSnitch for Linux"

littlesnitch — Fri, 10 Apr 2026 11:08:40 +0000

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.

New comment by littlesnitch in "LittleSnitch for Linux"

littlesnitch — Fri, 10 Apr 2026 11:06:35 +0000

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.

New comment by littlesnitch in "LittleSnitch for Linux"

littlesnitch — Fri, 10 Apr 2026 11:03:06 +0000

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.

New comment by littlesnitch in "LittleSnitch for Linux"

littlesnitch — Fri, 10 Apr 2026 11:00:27 +0000

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.

New comment by littlesnitch in "LittleSnitch for Linux"

littlesnitch — Fri, 10 Apr 2026 10:54:35 +0000

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.

New comment by littlesnitch in "LittleSnitch for Linux"

littlesnitch — Fri, 10 Apr 2026 10:39:30 +0000

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.

New comment by littlesnitch in "LittleSnitch for Linux"

littlesnitch — Thu, 09 Apr 2026 12:19:48 +0000

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.

New comment by littlesnitch in "LittleSnitch for Linux"

littlesnitch — Thu, 09 Apr 2026 12:14:26 +0000

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.

New comment by littlesnitch in "LittleSnitch for Linux"

littlesnitch — Thu, 09 Apr 2026 12:09:18 +0000

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.

New comment by littlesnitch in "LittleSnitch for Linux"

littlesnitch — Thu, 09 Apr 2026 12:05:33 +0000

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

New comment by littlesnitch in "LittleSnitch for Linux"

littlesnitch — Thu, 09 Apr 2026 11:02:14 +0000

eBPF programs are able to accuratly process network traffic in high performance, but the amount of CPU instructions you can use is limited. Otherwise it would not be high performance. This limits the complexity of in-kernel processing.