[1] "Little Snitch for Linux is built for privacy, not security, and that distinction matters. The macOS version can make stronger guarantees because it can have more complexity. On Linux, the foundation is eBPF, which is powerful but bounded: it has strict limits on storage size and program complexity. Under heavy traffic, cache tables can overflow, which makes it impossible to reliably tie every network packet to a process or a DNS name. And reconstructing which hostname was originally looked up for a given IP address requires heuristics rather than certainty. The macOS version uses deep packet inspection to do this more reliably. That's not an option here." -- from https://obdev.at/products/littlesnitch-linux/index.html
Use a filtering proxy instead and no gateway / route to the internet.
2) You're advising security through obscurity instead of a network namespace + firewall.
or DNS stubs with filtering capabilities.
And regarding failed reverse DNS names: Little Snitch is sniffing DNS lookups. If lookups are encrypted, there is little it can do. We usually recommend DNS encryption at the systemd layer, not at app layer. This way we can see lookups on 127.0.0.53 and the actual lookup sent out is still encrypted.
Also, it's currently only sniffing UDP lookups, not TCP. The eBPF part is already very close to the complexity limits (700k instructions of allowed 1M) and adding TCP parsing would exceed this limit. It should be possible to forbid TCP port 53 with a rule, though. Some complex DNS lookups will fail, but routine things should still work.
Perhaps there should be a mode where littlesnitch just does its own lookup using the system-configured rDNS, for example from the ui or for specific processes, etc? It should be cached if it is a recent lookup, so minimal performance implications; and offloaded to the system rDNS resolver, so minimal instruction set.
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.
Where LittleSnitch is definitely ahead is showing process connections over time after said process has been allowed.
As software should be.
I think it's fair to ask that a developer choosing to build a thing that requires that kind of access should be expected to err on the side of transparency.
https://github.com/evilsocket/opensnitch?tab=readme-ov-file#...
If users consider this software important they should donate so they can keep using it.
FOSS simply isn't sustainable if you want to make a living out of it. It protects a lot of user freedoms - even those that don't actually matter to users that much - at the expense of the rights of developers. There are a lot of ways that developers could be paid and users would still be protected (have access to source and the right to modify). The only ones benefitting from the current situation are BigTech.
/rant
> FOSS simply isn't sustainable if you want to make a living out of it.
This is probably true enough. Yet there are a million open source projects that existed, some for decades. There has go to be another way and another motivation.
> even those that don't actually matter to users that much - at the expense of the rights of developers
I would assume those developers would use a different license or even create their own terms.
> The only ones benefitting from the current situation are BigTech.
Paying the original developers will not change this. Big tech is big. They take whatever they can, sometimes killing the original project in the process. Perhaps a license like GPL is the solution to that particular problem.
I don't mean to come off snarky. I do agree with a lot of the things that you're saying but I see the free software movement as a completely voluntary and human thing. You could not get rid of it if you wanted. Paying for it is an auxiliary thing and concentrates too much on the wrong thing IMO. A lot of free software developers are already gainfully employed, some are millionaires. Yes some are struggling but then they are still voluntarily sharing their work with the whole world. That must mean they have their valid reasons for doing so.
Not exactly. Users still have the software. They don't have updates.
See the issue here? Even if someone just fixes some bugs and security fixes - this alone can be time consuming. At the same time many users can just accept the version without those pathes and don't donate.
So you have a choice - continue to maintain the software for less money or to drop it, leaving donating users with no support.