I'm not a Little Snitch or Open Snitch user, I wonder if these firewalls are able to block requests done with the use of some other, allow-listed program.
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:
It depends. Little Snitch for Linux has a two level namespace for processes. It takes the process doing the connection and its parent process into account when evaluating rules.
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.
With the literal rules described it would not be blocked. A more detailed rule (in Open Snitch at least, not as familiar with the other variants) could match e.g. whether the process's parent tree contained the python binary rather than just if python is the process binding the socket.
This gets even more involved when you consider things like loading libraries, there's also the impact of calls like OpenProcess/WriteProcessMemory/CreateRemoteThread (Windows-land versions, though I'm sure similar exists elsewhere).
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.
The SELinux MAC policy should restrict which files and ports each process may access. In general, most modern distro have this feature, but normal users do not go through the rules training and default enable flag setup. =3
Sorry, we have not tested on Fedora before release. Did not expect so much interest in the first hours after release...
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.
There's some good feedback in the GitHub issue on the subject, seems to happen on slightly newer versions of the kernel than the one you've tested on and affects other distros like Arch as well. I'll keep an eye on the discussion and test again once updates are ready.
"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!"
It crashed my Fedora 43 installation (maxed out CPU and RAM) right after installing from .rpm. After reboot it can't even load plasmashell. I'm typing this after booting into a Fedora 42 backup. 42!
Had the same issue on arch, though survived it OK (6.19.11-zen1-1-zen). Maybe it's a zen kernel thing, it only pegged 2-3 cores and the others were OK so could jump in and kill it.
Yeah, because no third party program has ever crashed on any other OS.
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.
Recently I was wondering how viable it is to launch a niche, paid tool for Linux. I found that this is a very rare model, most tools are either just free, supported by sponsorship, supported by some paid cloud-based service that accompanies the tool, use an open-core model with paid add-ons.
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.
Many from linux crowd are slightly paranoid and ideological.
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.
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...
The Wikipedia page for Little Snitch indicates that it's written in Objective-C. Is that still the case? Before going with the new implementation, did you attempt (or consider) to port the current codebase (using e.g. Cocotron or GNUStep libraries)? If so, how good or bad of an experience was that?
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?)
As a paying customer, I wasn't expecting this so thank you! Can you expand more on your gut feeling? Also, I have different security expectations on Linux vs MacOS. Would you ever consider open sourcing the daemon?
When OpenSnitch already exists and is free and open source, a paid tool that does essentially the same thing with a slightly different (perhaps more polished) UI would be quite a hard sell.
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).
I remember before Little Snitch there was ZoneAlarm for Windows[0] (here is a good screenshot[1]). No clue if the current version of ZoneAlarm does anything like that (have not used it in 2 decades). I always found it weird that Linux never really had anything like it.
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.
What I really liked about ZoneAlarm wasn't just that it was a very nice technology - and it was; but also that it got the user expectations and training right from a very early stage.
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...
Was working as an IT consultant. We got a call from an international manufacturer in the area for support. Local lead IT manager took down the firewall which infected their computer network around the world. All they wanted were bodies to help clean systems and apply OS updates.
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.
I helped administer the CheckPoint commercial version of this before 2010 in a large enterprise (Checkpoint Integrity it was badged as). Really good product though we did have some bugs with it - I do remember the developers from Israel got involved and were very capable.
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.
This reminded me of running Kerio Personal Firewall. When Kerio ended I switched to either ZA or Comodo firewall, one of them introduced a neat feature of running executables in containers. Made clicking random things so much easier. But the best part with all of these was restricting windows to where it could barely do anything. "RandomXYZ.DLL wants to execute random what and connect to random where? I dont think so MS." lol
Wow. Insane throwback. I think I first learned about ZoneAlarm from some PC magazine my parents bought for me. Completely forgot about this great piece of freemium!
if anyone else suddenly started wondering, PC magazines still exist in physical form. There are even still Linux magazines that come with installer CDs for distros. And all kinds of other magazines as well, like for Mac computers, for photo editors, for Raspberry Pi etc.
I ran ntop on a router in 2001. It had a highly insightful overview of traffic with nice looking diagrams and everything. There hasn't been anything like that since as far as I'm aware.
ZoneAlarm otoh, was snakeoil. Programs that ran at the same privilege level (typically everything) could bypass it in various ways.
There was also Tiny Firewall which got bought by Computer Associates around 2005. Probably the most complicated or fine grain control for me at that time in Windows XP.
This is what I used! At some point I managed to block DHCP lease renewals on my computer, and Internet would always stop working after a given timespan. Took a good while to figure out I caused the problem myself.
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)
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 to drill down connections (get from app requesting a domain being resolved to an IP and connecting on a port, and filter this at any level including globally; if the request was already filtered, you can see why and get to that filter to either remove it or add an exception)
No, the Windows firewall in its default configuration does not restrict outbound connections in any way. Any application can make any outbound connection it wants. If an application attempts to listen for incoming connections from external sources and there is not an existing policy, Windows will pop up a dialog asking the user if they want to allow this and if so whether it should be allowed to listen on all networks, only networks marked as "private", or for domain-bound corporate computers only networks where the domain controller is reachable.
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.
Okay hear me out, I use little snitch for a while. Great product. Love finding out what phones where. I make every single request (except my browser, because I'm fine with their sandbox) block until I approve.
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?
Disclaimer: I'm the developer of Little Snitch for Linux. Regarding MITM concerns: The eBPF component, which actually sees all the traffic, is Open Source (GPLv2). You can review it on Github and verify whether it sends any data to user space: https://github.com/obdev/littlesnitch-linux
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'm happy to see this on Linux and I really appreciate the open-sourcing of the eBPF component.
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).
Thank you for creating this. I tried running it on Raspberry Pi 5 (running debian trixie), but could not make it work. Does it require compiling in lieu of the .deb file you offer?
> 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.
disclaimer: I co-develop (FOSS) Little Snitch / Open Snitch inspired firewall but for Android
> 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
I just tried littlesnitch and it did not resolve very many ips to domains, which is pretty basic. It also failed to identify most processes, and they were grouped under "Not Identified". It appears these are known limitations of the Linux version [1]. So for that alone I need to stick with opensnitch.
[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
Regarding unidentified processes: Little Snitch daemon must have been running when the process started in order to identify it reliably. It's best to reboot after installation so that Little Snitch starts before everything else. I should probably note this somewhere.
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.
I guess that makes sense, since it's pretty new. OpenSnitch is great software in terms of functionality but I find the UI lacking. If LittleSnitch can keep the same functionality, while improving the UI, I'm switching. My other current concern here is that the LittleSnitch UI is just a Webview and I think it would be much better if there was a native option (ideally GTK-based for me, but Qt would also be acceptable). Webviews are slow and full of bloat.
"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." https://obdev.at/blog/little-snitch-for-linux/
I've used OpenSnitch for years, and while LittleSnitch definitely has a better UI for showing which process is making which connections over time, OpenSnitch does a pretty good job here. I get a modal popup when a program that hasn't made a connection tries to make a connection, and I can either allow/deny in one click, or further customize the rule e.g. allowing ntpd to connect, but only to pool.ntp.org on port 123.
Where LittleSnitch is definitely ahead is showing process connections over time after said process has been allowed.
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.
Wow. I have used Little Snitch on Mac for years, love this!
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.
> 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?
There was a similar Show HN from 3 weeks ago.
https://dialtoneapp.com/explore - but only 2 so far. Maybe LittleSnitch can generate more data than this? Could end up an immune system for bad actors.
Anything new to get much better performance from low-spec machines that is idiot-proof is a game-changer.
Probably should throw it out there that I'm building something inspired by littleSnitch for windows. Currently a bit stealthy about it. But when I crowd source the funding for a code signing cert I'll get it out there. Lots of inspiration from LittleSnitch, in spirit if not actual code.
I'd be curious to hear additional details if you can share - got a timeline, or somewhere I can enter my email address for updates? I'd love to alpha/beta test if you're looking for testers.
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.
Congrats to Linux users on getting a great tool from a quality development shop. Objective Development is one of our (Mac users) exemplars for attention to detail and fit & finish.
Congrats to Objective Development for expanding their well-loved tool to a new platform. You guys rock.
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.
Incredible. LittleSnitch is must-have for macOS and trying to get equivalent functionality on Linux was painful. So very happy to see this, and very happy to give the developers at Objective Development my money.
In linux, I trust most distro apps to run with network access without any sort of firewall. And for apps from internet, just put them in bubblewrap or run with flatpak without access to homedir, network, audio, video etc. depending on program.
I used Little Snitch on Mac a few years ago and liked it, though I wasn't a fan of how (necessarily) deep it had to be in the OS to work. It felt like one of those things where, the moment you have any kind of network connectivity issue, it's the first thing you need to disable to troubleshoot because it's the weirdest thing you're doing.
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.
I am the same, used Little Snitch for a few years back in the late 2000s, I think like 2010 until a few years back when I moved fulltime to Linux. Back then, my parents had an iMac and I was the designated "IT" person to keep it running efficiently. My siblings had a bad habit of installing games and hack software on it for their games. I ended up purchasing a license and after the first few hours/days of configuring allow/block lists, it worked pretty well. It earned the label of "Little B*ch" from them since it would stop their gaming hacking apps from connecting and wrecking havoc. Eventually I learned to keep them on a standard user account and separate admin for installing software.
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.
How deep it was in the OS was exactly what I liked about it. I only wished it were open source so I know what exactly is happening with that level of access.
i have been pretty happy with opensnitch. ui improvements are always welcome although what might be really interesting would be some sort of plug-in system that allows for an agent to watch my interactions activity and the outbound connections and only flag things that seem surprising. also maybe some kind of improvement over the pop-up (maybe get rid of them entirely and add some kind of cli wrapper that allow-lists child processes).
Is that true? If so, that’s not a good sign. I remember how impressed I was by ZoneAlarm in the early 2000s asking permission for itself to connect to the Internet, using the exact same dialogue it presented for any other program, with no dark patterns suggesting that the user should give preferential treatment to it.
Doesn't seem to be, I can see LittleSnitch itself connecting to yoyo.org and obdev.at. GP may be referencing a past bug, either in LittleSnitch or macOS.
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.
I’ve been researching the “best” way to build a little outbound network proxy to replace credential placeholders with the real secrets. Since this is designed to secure agents workloads, I figured I might as well add some domain blocking, and other outbound network controls, so I’ve been looking for Little-snitch-like apps to build on.
I’ve been surprised to find that there aren’t a ton of open source “filter and potentially block all outbound connections according to rules”. This seems like the sort of thing that would be in a lot of Linux admins’ toolkit, but I guess not! I appreciate these guys building and releasing this.
Something almost no firewalls get right is pausing connections (NOT rejecting them) until I've decided whether to allow or not. The only firewalls I've seen do this are Little Snitch for Mac, and Portmaster for Windows (before they made it adware / started locking existing local features behind the subscription).
Firewalls don't do this because they are built at the wrong layer to do proper pending calls. It's too narrow of a design space for most firewalls to care.
I use Portmaster (on Linux) and I have never seen ads (either in the app or apps that get their DNS from Portmaster) on it. About the only thing I saw different between the free version and the base level paid for version was traffic history and weekly reports (and badges on Discord if that's your kind of thing).
OpenSnitch seems to do this just fine? Unless I’m misunderstanding your point. Connections seem to just block until I take an action on the dialog. Now, if an application itself has specified a short timeout (looking at you, NodeJS-based stuff), that obviously doesn’t help. But for most software it works great.
I'm so surprised that so few people have heard of Portmaster, it's been around for years and runs on Linux (and Windows if you must). And if you don't need traffic history it's free.
I used to use a Windows firewall which basically hijacked a bunch of WinAPI calls and let me approve/deny every request. Trying to be a good secure boy I ran this setup for a while but it was exhausting. Every single action needed dozens of approval windows. After a while I removed the software. I reckon it is good situationally though, trying out a new program for first time (that isn't risky enough for a VM or sandbox), might be good to turn on a tool like this.
You are referring to the TCP three way handshake problem here. The macOS version is bound by the API provided by Apple: We get the API call for filtering only after the three way handshake has started.
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.
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.
The gold standard, which I haven't been able to achieve, is to be able to do a pi-hole/adguard style centralized control where I can allow youtube but block youtube shorts. All solutions I have seen talk about on-device setup which isn't an option given that I don't want to manage it on a per-device basis.
Because of the way youtube serves shorts the exact same way it serves any other video it sounds like a man-in-the-middle proxy server would be needed. which to enforce would still require per device config(loading corp style keys). A per device config that would probably be trickier than a shorts killer browser extension.
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.
You would have to break E2E encryption, no? I think, at the very least you still would have to manage new TLS certificates per device to MITM yourself. I mean, doable, but also kinda nasty.
I know it sounds crazy at this point, but with popular YouTubers switching to Linux, gamers overall well-aware of Steam on Linux advantages and switching as well, plus popular software like LittleSnitch getting ported, 2026 can without irony be named as Year of Linux Desktop, right?
I did the switch in 2013 and haven't missed it. For games I ran vga_passthrough and later VFIO and others until pretty recently (I think right after covid I switched to steam directly on linux)
For Linux desktop users. A bit of tongue-in-cheek but that's pretty much the argument that I've heard in some circles ("it works for us and not going away anytime soon - why waste time convincing others?").
I think there is a lot of talk (and this is good), but very little action. Market share is still incredibly low for LNX. I believe only a small subset of people actually attempt the jump from WIN to LNX (since most just want to play their games and run their programs without hassle) and then quickly realize that its tougher than they anticipated and swiftly return to WIN.
This is true, but also the original comment still stands: Linux desktop usage outside developers was so low that it was barely worth mentioning before, so even a small uptick like this is a serious change, and it's how bigger changes start.
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.
5% on the steam survey though. The jump isn't quite as big from previous years as it seems as they did some corrections to the statistics this year, but 5% is nothing to sneeze at.
As someone who did make the jump, it was actually a lot easier than I anticipated. I encourage others to do the same. The only games I can't play are some AAA multiplayer games I wasn't particularly interested in anyways.
Also unrelated, but more linux gamers proves my personal observation that on the spectrum of computer literacy gamers are just below powerusers and programmers. We see more less technical people migrate over to Linux gradually and now it's gamers turn. Well, that's kind of obvious for everybody except Microsoft apparently.
Wifi has been working out of the box for close to 20 years now. On some computers with old Broadcom cards, you have to enable non-free drivers. What model are you using?
WiFi works fine if there are drivers for whatever WiFi chip you have.
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.
Wifi and Bluetooth are pretty decent now. As far as I can tell the biggest blockers are:
* 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.
Will there ever be anything like Comodo Firewall's HIPS firewall on Linux [0]? I remember when firewalls like ZoneAlarm could detect keyboard hooks from keyloggers and such. Comodo Firewall has had this for over a decade, but unfortunately they are not free anymore. For how open Linux is, it surprises me you can't handle things apps are doing on an alert by alert basis, and not just network permissions. Firewalls used to detect DLL injections, apps creating script files to run, adding stuff to start up. Now it seems firewalls only means network detection.
Haven’t tried LittleSnitch, but from what I see it’s on par as far as features go. LuLu’s UI could use some improvements, but otherwise it’s perfectly fine for the job.
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.
This is correct, of course. But I currently can't make the entire project Open Source. My other option would be to keep it completely private (wrote it mostly for myself in the first place).
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.
My friend is building something similar to Little Snitch but specialized for sandboxing agents / monitoring their traffic / building rulesets to restrict traffic by "learning" from good runs. https://greywall.io/
Curious who else is working on stuff like this / what other solutions exist that are like "Little Snitch" for agent network + filesystem calls.
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.
It just depends on the UI frameworks available to developers and their interest in building something good-looking. Different UI frameworks are available for different platforms, and there are only a few good ones that are cross-platform. Qt and GTK are pretty common for linux apps and typically don't look great.
Related - I'm working on launching Watch.ly[0] (human-in-the-loop for remotely approving network and file system access for agents) in the next week or so. It works similarly, via eBPF (although we can also fall back to NFQUEUE). Supporting 5.x+ linux kernels[1], osx, and windows.
Did not know about LittleSnitch, will definitely check it out.
An operating system is roughly broken into three parts: the kernel, the core system tools, and the shell (the desktop environment and/or the CLI shell). Linux: Linux kernel, GNU coreutils (usually), KDE/Gnome/etc + CLI shells. macOS: XNU, BSD userland + launchd/etc, Aqua/Cocoa. Windows: NT kernel, Win32/WinRT/etc, Windows Shell.
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.
More the opposite. macOS is a veneer of nix, but underneath it is the XNU microkernel. Lots more nuance since Apple took over and added a lot of their own performance and API improvements to
You're correct, but for a bit more context: The macOS kernel is XNU, which is derived from/based on the Mach kernel, but heavily modified. The kernel itself is open source but some drivers/kernel extensions are not so it's not actually usable (unless you provide your own implementations of those).
When AI was first released to the public, one of the first things I did was create a linux version of little snitch, I doubt it worked as well as the original, but it did work well. Glad to see this released, it's a great app.
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.
Does anyone know how the blocking functionality works? I worked on some eBPF code a few years ago (when BTF/CO-RE was new), and while it was powerful, you couldn't just write to memory, or make function calls in the kernel.
Is there a userland component that's using something like iptables? (Can iptables block traffic originating from/destined to a specific process nowadays?)
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.
Just tried it on my laptop. Unfortunately, my laptop got extremely hot about 10 seconds after installation. The resource monitor showed that it was eating up all of my laptop's CPU. I panically stopped the service and uninstalled it before I could even open the web UI. It was a really poor first impression.
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.
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...)
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.
I'm glad people are building stuff for Linux, but the people who actually want something like this have likely already been using Opensnitch for years. I'm certainly not going to spend $60 for something that has been doing the job for free.
Yess, the return of the actually good landing page for the technically-minded. Now all they need to do is roll back the macOS one that looks and reads like it was designed by a marketing agency that knows nothing about computers (or even Little Snitch itself).
Back when I was still using macOS I loved Little Snitch and was a paying customer. And I agree nothing on Linux comes close. Would it be technically feasible to also provide this as a Flatpak to support immutable distros like Bazzite?
I’m not aware of flatpaks specifically having th capability to run system software, daemons, etc. Some other immutable packaging formats should be able to (systemd-sysext at least, and snap iirc).
Giving it a shot right now. Very easy setup, intuitive UI, but a lot of requests' processes are not identified (while they could easily be identified, as they belong to the browser that has some, but less, identified calls)
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.
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.
Thanks for the response. Sorry I should of been less vague. Paqet works on raw sockets with KCP. Though it's intended for good. What's to assume bad actors aren't also using this method to get around solutions like littlesnitch?
A recent example, but not the only is a Iran a botnet, using this to get around detection.
Awesome. I always felt Linux was missing a per-application firewall. I didn't dig much into it but at least iptables didn't have rules for that when I looked.
So if this is free to use on linux, what is to stop someone from doing what Colima did to Docker? Aka make a tiny Linux VM on MacOS and package Little Snitch within that?
It barely has any of the features of the MacOS version, there is no shortage of cracks for Little Snitch, and there is Lulu. Other than that, I am not sure.
Little Snitch requires packet inspection. If you ran it in a Linux VM, it will inspect packets within the VM. So... kind of useless for monitoring connections on the host.
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.
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.
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:
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.
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.
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?
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.
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...!
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.
> For keeping tabs on what your software is up to and blocking legitimate software from phoning home, Little Snitch for Linux works well. For hardening a system against a determined adversary, it's not the right tool.
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.
It’s not really necessary on Linux. Linux systems work without 40 invisible background services phoning home to the mothership to leak your hardware identifiers for FAA702 collection.
I run both (LS on Mac, at least), they do different things - pi.hole is a great ad blocker which applies to all of the devices on your network. Little Snitch is doing something different - it tells you every call that every app you use is making, and allows you to approve or deny each one. So, you can block telemetry for apps, or you can block certain apps from contacting certain servers, or you can just use it to watch what apps on your system are calling out to where.
To clarify, I'm aware that pihole is not intended to run on a client OS, and doesn't monitor at a process level. I'm focused on the intended effect rather than the process itself (blocking malicious/ad servers). And I think I framed my initial question incorrectly as if LS and PiHole as subtitutes. It's perfectly fine and even preferrable to use both as layered protection. I'm just thinking however when it comes for bang-for-buck it seems like PiHole is the better value proposition if you could only set up one.
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.
LittleSnitch isn't for ad blocking (only), it is for tracking/blocking/allowing ALL connections from various processes. PiHole only blocks DNS requests to known ad servers.
Completely different thing. A littlesnitch type thing is for all traffic. Pihole is a DNS query thing that prevents various ad content from being loaded. It's also trivially easy for a malicious application with network access to bypass any instance of pihole on your LAN by doing its own DNS over HTTPS lookups to its own set of server(s) by IP.
> 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
The above feels like an utter AI slop nonsense, sorry. I believe eBPF, the Linux Kernel feature, is absolutely capable for accuracy and perfect processing of network traffic.
Have you ever checked Calico or Cilium, or at least, Oryx?
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.
Thank you for the response. Yet, how the heck the CPU instructions you inject in (that are being processed within the same network processing) limit the capabilities of the flow, if you literally put your calls within the same networking context? Please provide any actual document that proves your point.
I have, but in the scopes of Kprobes non-network but memory. Here, I am sure you haven't at this point. I also provided projects you may check prior stating another nonsense. Instead, you could also provide some more evidence you disagree with.
I'm not a Little Snitch or Open Snitch user, I wonder if these firewalls are able to block requests done with the use of some other, allow-listed program.
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:
will this request be blocked?
It depends. Little Snitch for Linux has a two level namespace for processes. It takes the process doing the connection and its parent process into account when evaluating rules.
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.
With the literal rules described it would not be blocked. A more detailed rule (in Open Snitch at least, not as familiar with the other variants) could match e.g. whether the process's parent tree contained the python binary rather than just if python is the process binding the socket.
OK, I see, so a limitation is also that I cannot block an individual script, I need to block a Python interpreter.
1 reply →
Would it silently allow or would you still get the notif or whatever (iirc from littlesnitch years ago)?
1 reply →
This gets even more involved when you consider things like loading libraries, there's also the impact of calls like OpenProcess/WriteProcessMemory/CreateRemoteThread (Windows-land versions, though I'm sure similar exists elsewhere).
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.
The SELinux MAC policy should restrict which files and ports each process may access. In general, most modern distro have this feature, but normal users do not go through the rules training and default enable flag setup. =3
If the IP address of evil.com is not in the DNS data available to firefox, then it does not matter
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
Tried it on Fedora 43 (6.19.11 x86_64) and it loaded all CPU cores, dumped 50K lines in the journal and failed to start.
> 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.
Sorry, we have not tested on Fedora before release. Did not expect so much interest in the first hours after release...
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.
There's some good feedback in the GitHub issue on the subject, seems to happen on slightly newer versions of the kernel than the one you've tested on and affects other distros like Arch as well. I'll keep an eye on the discussion and test again once updates are ready.
From the download page on the website:
"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!"
Someone already created an issue for it: https://github.com/obdev/littlesnitch-linux/issues/1
It crashed my Fedora 43 installation (maxed out CPU and RAM) right after installing from .rpm. After reboot it can't even load plasmashell. I'm typing this after booting into a Fedora 42 backup. 42!
I was looking for a comment like yours. Same issue, in my case only eating up half of my cores but with 100% utilization, webUI not working.
Had the same issue on arch, though survived it OK (6.19.11-zen1-1-zen). Maybe it's a zen kernel thing, it only pegged 2-3 cores and the others were OK so could jump in and kill it.
Your average Linux experience.
And the second most upvoted comment is someone seriously asking if 2026 if the year of Linux desktop...
Yeah, because no third party program has ever crashed on any other OS.
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.
7 replies →
This is brand new open source software with like 3 stars on github
>The daemon (littlesnitch --daemon) is proprietary, but free to use and redistribute.
Worth noting that it is closed source. Would be worth contributing patches to OpenSnitch to bring it up to parity with Little Snitch.
https://github.com/evilsocket/opensnitch
Thanks for sharing Open Snitch
Nice to have this as an extra option, but being a linux user I value openness of code. I am pretty content with opensnitch + opensnitch-ui.
Recently I was wondering how viable it is to launch a niche, paid tool for Linux. I found that this is a very rare model, most tools are either just free, supported by sponsorship, supported by some paid cloud-based service that accompanies the tool, use an open-core model with paid add-ons.
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.
Many from linux crowd are slightly paranoid and ideological.
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.
> Many from linux crowd are slightly paranoid
Slightly? There are quite a few tin foil hat comments on this submission.
4 replies →
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...
The Wikipedia page for Little Snitch indicates that it's written in Objective-C. Is that still the case? Before going with the new implementation, did you attempt (or consider) to port the current codebase (using e.g. Cocotron or GNUStep libraries)? If so, how good or bad of an experience was that?
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?)
1. <https://obdev.at/index.html>
2. <https://obdev.at/products/littlesnitch/index.html>
4 replies →
As a paying customer, I wasn't expecting this so thank you! Can you expand more on your gut feeling? Also, I have different security expectations on Linux vs MacOS. Would you ever consider open sourcing the daemon?
1 reply →
When OpenSnitch already exists and is free and open source, a paid tool that does essentially the same thing with a slightly different (perhaps more polished) UI would be quite a hard sell.
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).
The author talks about his motivation right here: https://www.obdev.at/blog/little-snitch-for-linux/
It's not that arcane.
This has the author's blog post on it https://obdev.at/blog/little-snitch-for-linux/
I remember before Little Snitch there was ZoneAlarm for Windows[0] (here is a good screenshot[1]). No clue if the current version of ZoneAlarm does anything like that (have not used it in 2 decades). I always found it weird that Linux never really had anything like it.
[0]: https://en.wikipedia.org/wiki/ZoneAlarm
[1]: https://d2nwkt1g6n1fev.cloudfront.net/helpmax/wp-content/upl...
I wrote a program similar to this for AmigaOS many, many years ago. I would have been inspired by ZoneAlarm or a program like it.
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.
What I really liked about ZoneAlarm wasn't just that it was a very nice technology - and it was; but also that it got the user expectations and training right from a very early stage.
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...
Was working as an IT consultant. We got a call from an international manufacturer in the area for support. Local lead IT manager took down the firewall which infected their computer network around the world. All they wanted were bodies to help clean systems and apply OS updates.
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.
Completely forgot about ZoneAlarm. I remember using it in the early 2000s!
I read ZoneAlarm and it was like suddenly a part of my brain that went unvisited for 25 years lit up...
4 replies →
I helped administer the CheckPoint commercial version of this before 2010 in a large enterprise (Checkpoint Integrity it was badged as). Really good product though we did have some bugs with it - I do remember the developers from Israel got involved and were very capable.
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.
Such nostalgia! I probably forgot about it after switching over to Linux 25 years ago.
Same. And in a similar vein--AnalogX NetStat Live.
Same... Totally forgot about ZA.
Same!
1 reply →
> [ZoneAlarm] I always found it weird that Linux never really had anything like it.
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.
This is such a naive view on computer security. It’s not just about spyware, which is also not exclusive to commercial vendors.
22 replies →
This reminded me of running Kerio Personal Firewall. When Kerio ended I switched to either ZA or Comodo firewall, one of them introduced a neat feature of running executables in containers. Made clicking random things so much easier. But the best part with all of these was restricting windows to where it could barely do anything. "RandomXYZ.DLL wants to execute random what and connect to random where? I dont think so MS." lol
Who remembers BlackICE Defender tho?
https://archive.org/details/BlackICE_Defender
I was there for SoftICE and BlackICE.
Simpler times.
1 reply →
Wow. Insane throwback. I think I first learned about ZoneAlarm from some PC magazine my parents bought for me. Completely forgot about this great piece of freemium!
if anyone else suddenly started wondering, PC magazines still exist in physical form. There are even still Linux magazines that come with installer CDs for distros. And all kinds of other magazines as well, like for Mac computers, for photo editors, for Raspberry Pi etc.
I learned about it from Leo and Patrick on The Screen Savers
I ran ntop on a router in 2001. It had a highly insightful overview of traffic with nice looking diagrams and everything. There hasn't been anything like that since as far as I'm aware.
ZoneAlarm otoh, was snakeoil. Programs that ran at the same privilege level (typically everything) could bypass it in various ways.
Back in the Halo 2 days ZoneAlarm and Cain and Abel were the go-to host bridging and bluescreen programs.
A simpler time lol.
Used to use Outpost Firewall Pro, too.
Good old Halo 2 stand-bying. An absolute plague.
It's interesting hw lng it took for linux to get a user friendly application firewall like OpenSnitch
It's because there's no way to make universal kernel modules/drivers, like it is on Windows.
2 replies →
There was also Tiny Firewall which got bought by Computer Associates around 2005. Probably the most complicated or fine grain control for me at that time in Windows XP.
This is what I used! At some point I managed to block DHCP lease renewals on my computer, and Internet would always stop working after a given timespan. Took a good while to figure out I caused the problem myself.
4 replies →
For me it was Sygate personal firewall back on windows xp
i loved zonealarm! and also pained myself with all the little rules and upkeep lol
Linux users just browsed firewall logs.
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)
> I always found it weird that Linux never really had anything like it.
OpenSnitch must be like ten years old by now. I think also portmaster is somewhat similar too.
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 to drill down connections (get from app requesting a domain being resolved to an IP and connecting on a port, and filter this at any level including globally; if the request was already filtered, you can see why and get to that filter to either remove it or add an exception)
1 reply →
ZoneAlarm, assuming it still exists, would be at least 20 years old.
Back then there was also a nice ~$15 program called Net Limiter which allowed one to cap network speeds individually per program.
It was problematic, so we moved to blackice defender iirc
isn’t this essentially built into Windows these days? although it seems to come with a lot of programs pre-approved.
No, the Windows firewall in its default configuration does not restrict outbound connections in any way. Any application can make any outbound connection it wants. If an application attempts to listen for incoming connections from external sources and there is not an existing policy, Windows will pop up a dialog asking the user if they want to allow this and if so whether it should be allowed to listen on all networks, only networks marked as "private", or for domain-bound corporate computers only networks where the domain controller is reachable.
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.
Most of the windows firewalls tools are just front ends for the integrated one with more sensible defaults.
Iirc the firewall was already in XP. Maybe earlier but sp2 for sure.
Default allows everything though but you could even set outbound blocking rules. Cumbersome UI and no really good visibility though.
You gonna commit seppuku if you try to add rules with the built in one.
[flagged]
That website redirected my browser to a very sketchy website after a couple seconds.
Don't open it.
@dang
2 replies →
Okay hear me out, I use little snitch for a while. Great product. Love finding out what phones where. I make every single request (except my browser, because I'm fine with their sandbox) block until I approve.
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?
Disclaimer: I'm the developer of Little Snitch for Linux. Regarding MITM concerns: The eBPF component, which actually sees all the traffic, is Open Source (GPLv2). You can review it on Github and verify whether it sends any data to user space: https://github.com/obdev/littlesnitch-linux
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'm happy to see this on Linux and I really appreciate the open-sourcing of the eBPF component.
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).
1 reply →
Thank you for creating this. I tried running it on Raspberry Pi 5 (running debian trixie), but could not make it work. Does it require compiling in lieu of the .deb file you offer?
> 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.
Everything has a price though… (I also use little snitch)
28 replies →
disclaimer: I co-develop (FOSS) Little Snitch / Open Snitch inspired firewall but for Android
> 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
How does it compare to opensnitch? https://github.com/evilsocket/opensnitch
I just tried littlesnitch and it did not resolve very many ips to domains, which is pretty basic. It also failed to identify most processes, and they were grouped under "Not Identified". It appears these are known limitations of the Linux version [1]. So for that alone I need to stick with opensnitch.
[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
Regarding unidentified processes: Little Snitch daemon must have been running when the process started in order to identify it reliably. It's best to reboot after installation so that Little Snitch starts before everything else. I should probably note this somewhere.
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.
7 replies →
I guess that makes sense, since it's pretty new. OpenSnitch is great software in terms of functionality but I find the UI lacking. If LittleSnitch can keep the same functionality, while improving the UI, I'm switching. My other current concern here is that the LittleSnitch UI is just a Webview and I think it would be much better if there was a native option (ideally GTK-based for me, but Qt would also be acceptable). Webviews are slow and full of bloat.
Is there any DNS based software to do block/allow? Kinda lika what's present in CiliumNetworkPolicies in Kubernetes networking?
5 replies →
I wonder why LS can't be given access to systemd resolved stub resolver to get all my DNS lookups.
"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." https://obdev.at/blog/little-snitch-for-linux/
I've used OpenSnitch for years, and while LittleSnitch definitely has a better UI for showing which process is making which connections over time, OpenSnitch does a pretty good job here. I get a modal popup when a program that hasn't made a connection tries to make a connection, and I can either allow/deny in one click, or further customize the rule e.g. allowing ntpd to connect, but only to pool.ntp.org on port 123.
Where LittleSnitch is definitely ahead is showing process connections over time after said process has been allowed.
3 replies →
Not sure, I was wondering the same, opensnitch is what I have installed but its not on currently, I probably got tired of it for whatever reason.
[dead]
It is free, no subscription at all and truly open source.
As software should be.
how should maintainer make money?
16 replies →
Congrats on the Linux port, this looks very nice.
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.
Very nice, I will give it a try later
Wow. I have used Little Snitch on Mac for years, love this!
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!
Also from [0].
> 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?
[0] https://obdev.at/blog/little-snitch-for-linux/
Two of the three components of LittleSnitch for Linux are open source. The eBPF (kernel portion) and UI are fully open 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.
Yep, I trust the obdev.at / Snitch guys.
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.
35 replies →
There was a similar Show HN from 3 weeks ago. https://dialtoneapp.com/explore - but only 2 so far. Maybe LittleSnitch can generate more data than this? Could end up an immune system for bad actors.
Anything new to get much better performance from low-spec machines that is idiot-proof is a game-changer.
Probably should throw it out there that I'm building something inspired by littleSnitch for windows. Currently a bit stealthy about it. But when I crowd source the funding for a code signing cert I'll get it out there. Lots of inspiration from LittleSnitch, in spirit if not actual code.
I'd be curious to hear additional details if you can share - got a timeline, or somewhere I can enter my email address for updates? I'd love to alpha/beta test if you're looking for testers.
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.
It's a custom WFP driver. No timeline yet..
If you or I guess anyone is curious sereno[hyphen]alpha[dot]ramble[thenumberoftechn9ne'sfavoriterum]@passinbox.com
2 replies →
Congrats to Linux users on getting a great tool from a quality development shop. Objective Development is one of our (Mac users) exemplars for attention to detail and fit & finish.
Congrats to Objective Development for expanding their well-loved tool to a new platform. You guys rock.
>attention to detail
Why does LittleSnitch (Mac) pre-resolve IP addresses, before user presses Accept/Deny?
IMHO DNS queries shouldn't initiate without user input.
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.
3 replies →
Question for devs, not me.
8 replies →
Incredible. LittleSnitch is must-have for macOS and trying to get equivalent functionality on Linux was painful. So very happy to see this, and very happy to give the developers at Objective Development my money.
In linux, I trust most distro apps to run with network access without any sort of firewall. And for apps from internet, just put them in bubblewrap or run with flatpak without access to homedir, network, audio, video etc. depending on program.
[dead]
I used Little Snitch on Mac a few years ago and liked it, though I wasn't a fan of how (necessarily) deep it had to be in the OS to work. It felt like one of those things where, the moment you have any kind of network connectivity issue, it's the first thing you need to disable to troubleshoot because it's the weirdest thing you're doing.
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.
I am the same, used Little Snitch for a few years back in the late 2000s, I think like 2010 until a few years back when I moved fulltime to Linux. Back then, my parents had an iMac and I was the designated "IT" person to keep it running efficiently. My siblings had a bad habit of installing games and hack software on it for their games. I ended up purchasing a license and after the first few hours/days of configuring allow/block lists, it worked pretty well. It earned the label of "Little B*ch" from them since it would stop their gaming hacking apps from connecting and wrecking havoc. Eventually I learned to keep them on a standard user account and separate admin for installing software.
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.
I’ve also wanted something like this. The challenge is with an external appliance you lose awareness of which process is initiating the request.
This is solvable to some degree but requires varying degrees of new complexity depending how smooth of a user experience you’re aiming for.
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.
How deep it was in the OS was exactly what I liked about it. I only wished it were open source so I know what exactly is happening with that level of access.
i have been pretty happy with opensnitch. ui improvements are always welcome although what might be really interesting would be some sort of plug-in system that allows for an agent to watch my interactions activity and the outbound connections and only flag things that seem surprising. also maybe some kind of improvement over the pop-up (maybe get rid of them entirely and add some kind of cli wrapper that allow-lists child processes).
LittleSnitch doesn't tattle on itself phoning home.
Is that true? If so, that’s not a good sign. I remember how impressed I was by ZoneAlarm in the early 2000s asking permission for itself to connect to the Internet, using the exact same dialogue it presented for any other program, with no dark patterns suggesting that the user should give preferential treatment to it.
Doesn't seem to be, I can see LittleSnitch itself connecting to yoyo.org and obdev.at. GP may be referencing a past bug, either in LittleSnitch or macOS.
2 replies →
Any proofs for this claim?
It does… and if it didn’t it would be trivial to prove.
How does it compare to Portmaster?
https://news.ycombinator.com/item?id=29761978
Portmaster – Open-source network monitor and firewall [315 points | 113 comments]
https://news.ycombinator.com/submitted?id=davegson
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.
I’ve been researching the “best” way to build a little outbound network proxy to replace credential placeholders with the real secrets. Since this is designed to secure agents workloads, I figured I might as well add some domain blocking, and other outbound network controls, so I’ve been looking for Little-snitch-like apps to build on. I’ve been surprised to find that there aren’t a ton of open source “filter and potentially block all outbound connections according to rules”. This seems like the sort of thing that would be in a lot of Linux admins’ toolkit, but I guess not! I appreciate these guys building and releasing this.
Something almost no firewalls get right is pausing connections (NOT rejecting them) until I've decided whether to allow or not. The only firewalls I've seen do this are Little Snitch for Mac, and Portmaster for Windows (before they made it adware / started locking existing local features behind the subscription).
Firewalls don't do this because they are built at the wrong layer to do proper pending calls. It's too narrow of a design space for most firewalls to care.
1 reply →
I use Portmaster (on Linux) and I have never seen ads (either in the app or apps that get their DNS from Portmaster) on it. About the only thing I saw different between the free version and the base level paid for version was traffic history and weekly reports (and badges on Discord if that's your kind of thing).
1 reply →
OpenSnitch seems to do this just fine? Unless I’m misunderstanding your point. Connections seem to just block until I take an action on the dialog. Now, if an application itself has specified a short timeout (looking at you, NodeJS-based stuff), that obviously doesn’t help. But for most software it works great.
I'm so surprised that so few people have heard of Portmaster, it's been around for years and runs on Linux (and Windows if you must). And if you don't need traffic history it's free.
portmaster is the tool i use for upgrading installed ports on freebsd since… like… olden times.
I used to use a Windows firewall which basically hijacked a bunch of WinAPI calls and let me approve/deny every request. Trying to be a good secure boy I ran this setup for a while but it was exhausting. Every single action needed dozens of approval windows. After a while I removed the software. I reckon it is good situationally though, trying out a new program for first time (that isn't risky enough for a VM or sandbox), might be good to turn on a tool like this.
Does it leak your IP like the Mac version?
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?
You are referring to the TCP three way handshake problem here. The macOS version is bound by the API provided by Apple: We get the API call for filtering only after the three way handshake has started.
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.
>> The macOS version uses deep packet inspection to do this more reliably. That's not an option here.
I thought it would be easier to do DPI on Linux than macOS. No???
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.
Yeah I thought that was one of the primary use cases of eBPF. Not an expert though, just read about some of these things.
The gold standard, which I haven't been able to achieve, is to be able to do a pi-hole/adguard style centralized control where I can allow youtube but block youtube shorts. All solutions I have seen talk about on-device setup which isn't an option given that I don't want to manage it on a per-device basis.
Because of the way youtube serves shorts the exact same way it serves any other video it sounds like a man-in-the-middle proxy server would be needed. which to enforce would still require per device config(loading corp style keys). A per device config that would probably be trickier than a shorts killer browser extension.
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.
You would have to break E2E encryption, no? I think, at the very least you still would have to manage new TLS certificates per device to MITM yourself. I mean, doable, but also kinda nasty.
I've been using Simplewall on Windows for a while but I think it's not maintained anymore. Need to find an alternative
Fort Firewall is my tool of choice. Each connection requires explicit approval.
same with simplewall
I know it sounds crazy at this point, but with popular YouTubers switching to Linux, gamers overall well-aware of Steam on Linux advantages and switching as well, plus popular software like LittleSnitch getting ported, 2026 can without irony be named as Year of Linux Desktop, right?
The year of the Linux Desktop will always be $CURRENT_YEAR + 1
To me, the year's in the past. I haven't touched Windows since 2017, and nothing bad happened to me.
But you're right, I guess for some people, there will already be a good reason not to use Linux.
What do you call a fallacy where it is implied that the future will be like the past?
5 replies →
I did the switch in 2013 and haven't missed it. For games I ran vga_passthrough and later VFIO and others until pretty recently (I think right after covid I switched to steam directly on linux)
The year of the Linux Desktop will be powered by fusion.
> 2026 can without irony be named as Year of Linux Desktop, right?
For whom? Average desktop users? Average users don't know what LittleSnitch is, let alone calling it "popular software."
For Linux desktop users. A bit of tongue-in-cheek but that's pretty much the argument that I've heard in some circles ("it works for us and not going away anytime soon - why waste time convincing others?").
That's some beautiful, text-book straw man!
1 reply →
I think there is a lot of talk (and this is good), but very little action. Market share is still incredibly low for LNX. I believe only a small subset of people actually attempt the jump from WIN to LNX (since most just want to play their games and run their programs without hassle) and then quickly realize that its tougher than they anticipated and swiftly return to WIN.
This is true, but also the original comment still stands: Linux desktop usage outside developers was so low that it was barely worth mentioning before, so even a small uptick like this is a serious change, and it's how bigger changes start.
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.
2 replies →
5% on the steam survey though. The jump isn't quite as big from previous years as it seems as they did some corrections to the statistics this year, but 5% is nothing to sneeze at.
4 replies →
As someone who did make the jump, it was actually a lot easier than I anticipated. I encourage others to do the same. The only games I can't play are some AAA multiplayer games I wasn't particularly interested in anyways.
1 reply →
What’s with the weird abbreviations?
4 replies →
I hope more and more folks who want gaming computers realize how turnkey bazzite is, especially if you’re team red. It’s pretty remarkable
2026 is the year of the linux phone. We need to embrace that the year of the linux desktop (2025) was successful.
According to latest Steam stats[0], Linux hit > 5% for the first time ever, so definitely successful (to some degree).
[0] https://store.steampowered.com/hwsurvey/steam-hardware-softw...
I wish. I'm tired of not owning my phone. But I don't see a push being done to get a proper Linux phone
Sadly year of the linux phone feels like it's getting farther away.
What does "the year of the Linux phone" mean when half the phones already run Linux?
2 replies →
France is trying to switch to desktop linux. https://news.ycombinator.com/item?id=47716043 and https://news.ycombinator.com/item?id=47719486
I think AI also makes it easier to deal with issues that come up.
Also unrelated, but more linux gamers proves my personal observation that on the spectrum of computer literacy gamers are just below powerusers and programmers. We see more less technical people migrate over to Linux gradually and now it's gamers turn. Well, that's kind of obvious for everybody except Microsoft apparently.
kde linux may make it happen. that and command line agents that help people fix their systems.
It’s definitely what converted me (steamOS first real experience, then mint, pop, and now bazzite)
does wifi work yet? last year it didnt for me
Wifi has been working out of the box for close to 20 years now. On some computers with old Broadcom cards, you have to enable non-free drivers. What model are you using?
WiFi works fine if there are drivers for whatever WiFi chip you have.
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.
Did you forget your WiFi password?
Wifi and Bluetooth are pretty decent now. As far as I can tell the biggest blockers are:
* 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.
2 replies →
yes
No.
Will there ever be anything like Comodo Firewall's HIPS firewall on Linux [0]? I remember when firewalls like ZoneAlarm could detect keyboard hooks from keyloggers and such. Comodo Firewall has had this for over a decade, but unfortunately they are not free anymore. For how open Linux is, it surprises me you can't handle things apps are doing on an alert by alert basis, and not just network permissions. Firewalls used to detect DLL injections, apps creating script files to run, adding stuff to start up. Now it seems firewalls only means network detection.
[0] https://help.comodo.com/uploads/Comodo%20Internet%20Security...
I use Lulu on my mac. Is it good enough (compared to LittleSnitch)?
Haven’t tried LittleSnitch, but from what I see it’s on par as far as features go. LuLu’s UI could use some improvements, but otherwise it’s perfectly fine for the job.
I would say it's better.
As articulated in the author's own blog post:
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.
This is correct, of course. But I currently can't make the entire project Open Source. My other option would be to keep it completely private (wrote it mostly for myself in the first place).
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.
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.
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.
My friend is building something similar to Little Snitch but specialized for sandboxing agents / monitoring their traffic / building rulesets to restrict traffic by "learning" from good runs. https://greywall.io/
Curious who else is working on stuff like this / what other solutions exist that are like "Little Snitch" for agent network + filesystem calls.
Also see Safing Port master:
https://safing.io/
LittleSnitch for Mac is a good looking app.
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?
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.
It just depends on the UI frameworks available to developers and their interest in building something good-looking. Different UI frameworks are available for different platforms, and there are only a few good ones that are cross-platform. Qt and GTK are pretty common for linux apps and typically don't look great.
Unfortunately it significantly impacts battery life, at least at my tests.
For comparison a single use case, what are the top linux tools used today to quickly list/watch which program/process made outbound to where?
Related - I'm working on launching Watch.ly[0] (human-in-the-loop for remotely approving network and file system access for agents) in the next week or so. It works similarly, via eBPF (although we can also fall back to NFQUEUE). Supporting 5.x+ linux kernels[1], osx, and windows.
Did not know about LittleSnitch, will definitely check it out.
[0] https://watch.ly/
[1] https://app.watch.ly/status/
> The macOS version uses deep packet inspection to do this more reliably. That's not an option here.
Isn't MacOS just *nix under the hood? Genuinely curious about this difference.
An operating system is roughly broken into three parts: the kernel, the core system tools, and the shell (the desktop environment and/or the CLI shell). Linux: Linux kernel, GNU coreutils (usually), KDE/Gnome/etc + CLI shells. macOS: XNU, BSD userland + launchd/etc, Aqua/Cocoa. Windows: NT kernel, Win32/WinRT/etc, Windows Shell.
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.
More the opposite. macOS is a veneer of nix, but underneath it is the XNU microkernel. Lots more nuance since Apple took over and added a lot of their own performance and API improvements to
From what I understand, macOS uses weird kernel implementation, which is almost open source, but not 100%
You're correct, but for a bit more context: The macOS kernel is XNU, which is derived from/based on the Mach kernel, but heavily modified. The kernel itself is open source but some drivers/kernel extensions are not so it's not actually usable (unless you provide your own implementations of those).
BSD family with fewer GPL parts each year
When AI was first released to the public, one of the first things I did was create a linux version of little snitch, I doubt it worked as well as the original, but it did work well. Glad to see this released, it's a great app.
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.
Does anyone know how the blocking functionality works? I worked on some eBPF code a few years ago (when BTF/CO-RE was new), and while it was powerful, you couldn't just write to memory, or make function calls in the kernel.
Is there a userland component that's using something like iptables? (Can iptables block traffic originating from/destined to a specific process nowadays?)
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.
Just tried it on my laptop. Unfortunately, my laptop got extremely hot about 10 seconds after installation. The resource monitor showed that it was eating up all of my laptop's CPU. I panically stopped the service and uninstalled it before I could even open the web UI. It was a really poor first impression.
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.
> Compatible with Linux kernel 6.12 or higher
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...)
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.
Ohhh interesting. Little snitch is one of 2 apps I miss from when the Mac was my daily driver. The other app was pixelmator
I'm glad people are building stuff for Linux, but the people who actually want something like this have likely already been using Opensnitch for years. I'm certainly not going to spend $60 for something that has been doing the job for free.
From the related blog post[0]:
> You can find Little Snitch for Linux here[1]. It is free, and it will stay that way.
[0]: https://obdev.at/blog/little-snitch-for-linux/
[1]: https://obdev.at/products/littlesnitch-linux
Yess, the return of the actually good landing page for the technically-minded. Now all they need to do is roll back the macOS one that looks and reads like it was designed by a marketing agency that knows nothing about computers (or even Little Snitch itself).
Back when I was still using macOS I loved Little Snitch and was a paying customer. And I agree nothing on Linux comes close. Would it be technically feasible to also provide this as a Flatpak to support immutable distros like Bazzite?
I’m not aware of flatpaks specifically having th capability to run system software, daemons, etc. Some other immutable packaging formats should be able to (systemd-sysext at least, and snap iirc).
As far as I can tell, Flatpak does not allow a daemon running as root early during system boot.
Giving it a shot right now. Very easy setup, intuitive UI, but a lot of requests' processes are not identified (while they could easily be identified, as they belong to the browser that has some, but less, identified calls)
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.
I wish applications like this could coordinate with upstream firewall like opnsense
Does little snitch and similar software work against solutions like Paqet?
https://github.com/hanselime/paqet
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.
Thanks for the response. Sorry I should of been less vague. Paqet works on raw sockets with KCP. Though it's intended for good. What's to assume bad actors aren't also using this method to get around solutions like littlesnitch?
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...
1 reply →
One person's (not my) take on why to skip this: https://the.unknown-universe.co.uk/privacy-security/little-s...
TL;DR it's closed source and there's open source alternatives.
Awesome. I always felt Linux was missing a per-application firewall. I didn't dig much into it but at least iptables didn't have rules for that when I looked.
For what it's worth, this is basically why and how I run MalwareBytes Windows Firewall Control
So if this is free to use on linux, what is to stop someone from doing what Colima did to Docker? Aka make a tiny Linux VM on MacOS and package Little Snitch within that?
It barely has any of the features of the MacOS version, there is no shortage of cracks for Little Snitch, and there is Lulu. Other than that, I am not sure.
I don't think it'll have access to the macOS connections, and certainly cannot act at the kernel-supported level as a firewall on the Mac side.
Little Snitch requires packet inspection. If you ran it in a Linux VM, it will inspect packets within the VM. So... kind of useless for monitoring connections on the host.
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.
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.
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.
then it pretty obviously is not better?
I really want Little Snitch for iOS.
Hopefully Apple makes the necessary frameworks available on iOS in general. Not only for supervised devices.
Same.
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)
> One thing to be aware of: the .lsrules format from Little Snitch on macOS is not compatible with the Linux version.
Why?
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.
You should add this feature.
Probably because it relies on eBPF rules on Linux?
I hope they provide a binary without dynamic libraries so that we can use this on nixos as well
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.
patchelf works on binaries. It's also possible to run a binary in a filesystem namespace with the dynamic libraries mapped.
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?
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.
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...!
I'd like to point out it uses very little memory, barely 33MB here. That's impressive!
Is there a way to kill little snitch completely without screwing up my DNS/other things?
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.
> For keeping tabs on what your software is up to and blocking legitimate software from phoning home, Little Snitch for Linux works well. For hardening a system against a determined adversary, it's not the right tool.
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.
Low-effort take: can't you just run ss -tulpn repeatedly and parse the output?
Neat! Too bad it's proprietary closed-source though (at least the daemon is).
doesn't work on arch (btw)
How does this work with WSL2? Will it monitor windows traffic as well?
It won't work with WSL because WSL does not provide eBPF, as far as I know.
Old bottle with new lable, but good to keep eye on interfaces
FYI: It's an Austrian company behind that software.
/proc/net/nf_conntrack ?
It’s not really necessary on Linux. Linux systems work without 40 invisible background services phoning home to the mothership to leak your hardware identifiers for FAA702 collection.
Linux maybe, not so true of all the DEs and apps installed on it
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.
The ultimate turnaround would be if the little snitch is snitching on the user too.
so a firewall for linux then?
Finally!
Dope.
Why would one use this over PiHole?
This is different. This shows you what in your operating system is making connections out and to where.
I run both (LS on Mac, at least), they do different things - pi.hole is a great ad blocker which applies to all of the devices on your network. Little Snitch is doing something different - it tells you every call that every app you use is making, and allows you to approve or deny each one. So, you can block telemetry for apps, or you can block certain apps from contacting certain servers, or you can just use it to watch what apps on your system are calling out to where.
To clarify, I'm aware that pihole is not intended to run on a client OS, and doesn't monitor at a process level. I'm focused on the intended effect rather than the process itself (blocking malicious/ad servers). And I think I framed my initial question incorrectly as if LS and PiHole as subtitutes. It's perfectly fine and even preferrable to use both as layered protection. I'm just thinking however when it comes for bang-for-buck it seems like PiHole is the better value proposition if you could only set up one.
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.
3 replies →
LittleSnitch isn't for ad blocking (only), it is for tracking/blocking/allowing ALL connections from various processes. PiHole only blocks DNS requests to known ad servers.
Completely different thing. A littlesnitch type thing is for all traffic. Pihole is a DNS query thing that prevents various ad content from being loaded. It's also trivially easy for a malicious application with network access to bypass any instance of pihole on your LAN by doing its own DNS over HTTPS lookups to its own set of server(s) by IP.
I mean, if you're at the point where your machine is compromised by a process with full network access little snitch won't help much either.
1 reply →
good
Now I can spy on the software spying at me. Nice.
Really like Lulu as an alternative to LittleSnitch https://objective-see.org/products/lulu.html
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[flagged]
The above feels like an utter AI slop nonsense, sorry. I believe eBPF, the Linux Kernel feature, is absolutely capable for accuracy and perfect processing of network traffic.
Have you ever checked Calico or Cilium, or at least, Oryx?
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.
Thank you for the response. Yet, how the heck the CPU instructions you inject in (that are being processed within the same network processing) limit the capabilities of the flow, if you literally put your calls within the same networking context? Please provide any actual document that proves your point.
I guess you haven't actually implemented anything in eBPF.
Can you elaborate? I thought eBPF was created to be used in high performance scenarios, so I am confused why this shouldn't be posssible.
1 reply →
I have, but in the scopes of Kprobes non-network but memory. Here, I am sure you haven't at this point. I also provided projects you may check prior stating another nonsense. Instead, you could also provide some more evidence you disagree with.