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.

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.

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.

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

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.

eBPF limits the size of the code, its complexity and how data can be stored. You cannot just implement any algorithm in eBPF for that reason.

That's not only a weakness, it's also a strength of eBPF. This way it can provide security and safety guarantees on the code loaded into the kernel.

We have not detected a targeted attack yet. On the Mac side, we are safe: No dependencies on any third party libraries. Only Apple.

On the Linux side, there is no single big vendor such as Apple who provides all the necessary libraries. I have tried to choose reputable sources from crates.io only, but to be honest, I don't know a secure solution to the problem.

Little Snitch is not there to replace OpenSnitch. It's just an additional option you can choose from. Some people might prefer it, others not.

Which one? Mac or Linux? For the Linux Snitch, just stop the service. For the macOS Snitch, you need to move the app to the trash via Finder. Only Apple can remove the network extension and they do this only when deleted via Finder.

Just because I did not port the parser for it to Rust. And I thought that the lsrules format is rare for blocklists. If there is popular demand, we can add it.

eBPF is extended in every kernel version. There is a layer where you get network packets and return a verdict. Little Snitch uses this type of eBPF function. You can look at the sources on Github.

In theory, it could be possible to get the requirement down to 5.17, but I don't get around the verifier constraints on pre 6.12 kernels. Maybe somebody who is more experienced with eBPF and the verifier can help. This part is Open Source and you can replace it.

Little Snitch must be running when the process starts in order to identify it correctly. You get less "Not Identified" if you run it for a while, or you should get none if you reboot and Little Snitch can start before everything else.

I would love to fix this requirement, but have not found a way yet.

As far as I can tell, Flatpak does not allow a daemon running as root early during system boot.

Little Snitch is bound to the API provided by Apple. The NEFilterDataProvider API calls `handleNewFlow()` only after sending out the first IP packet.

Version 6 added DNS encryption and in principle we could filter lookups (similar to PiHole) at this level. That brings other issues, though: This filter is system-wide, so process-specific rules (and overrides) would not work. And results can be cached by mDNSResponder. So when a blocklist causes an issue, you may not be able to fix it by simply disabling the blocklist. But it's still something we consider.