Top
Best
New

Posted by pluc 1 day ago

LittleSnitch for Linux(obdev.at)
1282 points | 418 commentspage 7
Jakson_Tate 18 hours ago|
cool to see eBPF used for a desktop firewall instead of just ddos packet dropping. the note about bpf map overflows is super relatable, dealing with that on bare-metal is a pain.

my question is... if the tracking maps fill up completely, does the daemon fail-open or fail-closed?

littlesnitch 17 hours ago|
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.

Jakson_Tate 1 hour ago||
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...!

wodenokoto 22 hours ago||
Honestly I think it is odd such a tool isnøt considered as standard to an OS as a process manager.

Anyway, this one looks great. I hope Linux distros will incorporate this or similar into the network widgets.

joeiq 16 hours ago||
Finally!
spwa4 16 hours ago||
Of course, getting data uploads past little snitch is an exercise in triviality. For instance, using DNS tunneling. Sending requests to unrelated servers, ideally on AWS or some other cloud, so you have no idea at all who's behind the server and the firewall can't realistically block it, where the info can be retrieved by another party.
dark-star 19 hours ago||
Neat! Too bad it's proprietary closed-source though (at least the daemon is).
smashah 20 hours ago||
Is there a way to kill little snitch completely without screwing up my DNS/other things?
littlesnitch 18 hours ago|
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.
akimbostrawman 22 hours ago||
i will never understand why people will flock to this but opensnitch which is just better, fully open and has existed for longer (on linux) gets ignored.
littlesnitch 18 hours ago||
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.
akimbostrawman 8 hours ago||
there is little reason to use two application firewalls at once so at least functionally it can replace it. ofc it will still keep existing regardless and i do appreciate the steps towards going open source.
RamblingCTO 22 hours ago||
then it pretty obviously is not better?
imagetic 1 day ago||
Dope.
chris_wot 1 day ago|
Can someone elaborate on the limitations bit?

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

Is this a limitation of the eBPF implementation? Pardon my ignorance, I'm genuinely curious about this.

littlesnitch 18 hours ago|
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.

More comments...