Little Snitch Lands on Linux, and the Hard Problem It Had to Solve First

Objective Development just announced Little Snitch for Linux, and the HackerNews thread is worth reading for the reactions alone. People who have been waiting a decade for a polished per-application outbound firewall on Linux are cautiously pleased. People who think OpenSnitch already solved this are skeptical. Both reactions are reasonable, and the gap between them is actually a technical story.

The original Little Snitch on macOS has been the gold standard for this category since the early 2000s. You run it, and any time a process attempts an outbound network connection, a window appears asking whether you want to allow it, for how long, and to which destination. Rules accumulate over time into a profile. The Network Monitor shows live per-process traffic. It is simple to use and technically sound. What made it work on macOS was a privileged kernel API that gave the application process attribution at the moment of the connection attempt, with no race conditions and with code-signing verification baked in.

Linux never had that API, and that absence is why the problem went largely unsolved for so long.

The Race Condition at the Heart of Early Linux App Firewalls

When a process on Linux calls connect(), the kernel records the new socket in the connection tracking table accessible at /proc/net/tcp (and /proc/net/tcp6 for IPv6). The socket is identified by inode number. To find out which process owns that socket, you scan /proc/*/fd/ looking for a symlink pointing to a socket with that inode. Once you have the pid, you read /proc/pid/exe for the binary path.

This approach sounds workable, and early tools used it. The problem is timing. By the time a userspace daemon receives a packet from NFQUEUE, does the inode lookup, scans the entire /proc fd directory tree, and resolves the executable path, the process may have exec’d into a different binary, forked, exited, or handed the socket off to another process via a Unix domain socket transfer. The inode you found might now belong to something completely different from what initiated the connection. This is a textbook time-of-check-to-time-of-use (TOCTOU) race, and it is not a theoretical edge case; it happens under normal system load.

OpenSnitch, the open-source Little Snitch-inspired tool originally written by Simone Margaritelli, hit this problem early in its history. The Python prototype was replaced with a Go rewrite, and the Go version iterated through several approaches to process attribution before settling on eBPF in version 1.6 as the only reliable mechanism. Portmaster, another contender in this space, went a different direction and built a custom kernel module, which works but comes with the DKMS maintenance burden that every Linux kernel module carries.

How eBPF Changes the Equation

The key breakthrough is the BPF_PROG_TYPE_CGROUP_SOCK_ADDR program type, available since kernel 4.17 (released mid-2018). This lets you attach an eBPF program to the cgroup connect4 and connect6 hooks, which fire synchronously at the point of the connect() syscall, before the connection proceeds. At that exact moment, the calling process’s task_struct is on the kernel stack, and the following helpers return accurate, race-free information:

// Inside a BPF_PROG_TYPE_CGROUP_SOCK_ADDR program
u64 pid_tgid = bpf_get_current_pid_tgid();
u32 pid = pid_tgid >> 32;

char comm[16];
bpf_get_current_comm(&comm, sizeof(comm));

u64 cgroup_id = bpf_get_current_cgroup_id();

There is no scan of /proc. There is no window during which the process can change. The attribution is atomic with the syscall itself. The eBPF program writes this information into a ring buffer (BPF_MAP_TYPE_RINGBUF, stable since kernel 5.8), the userspace daemon reads it, checks its rule set, and returns a verdict via a shared eBPF map. If no rule matches, the daemon can suspend the connection and present the user with a prompt.

This is the architecture that makes a reliable per-process firewall possible on Linux without a kernel module. Little Snitch for Linux almost certainly uses this approach, given that it is both technically superior and avoids the distribution-specific DKMS headaches of a custom kmod. The practical kernel requirement lands somewhere around 5.10 or 5.15, both of which are long-term support releases with broad distro coverage at this point.

What macOS Had That Linux Still Does Not

Even with eBPF making the implementation sound, there is one capability gap that matters. On macOS, Little Snitch uses the NetworkExtension framework’s NEFilterDataProvider API, which provides not just the originating pid but also the code-signing identity of the binary. This means Little Snitch can distinguish between a legitimate curl binary and a malicious binary that has been renamed to curl or placed at a different path. The kernel validates the code signature before handing over the attribution.

Linux has no equivalent. Process identity is path-based, derived from /proc/pid/exe. A sophisticated piece of malware can name itself anything, place itself anywhere, and the firewall sees a binary path with no additional verification. This is not a flaw in Little Snitch for Linux specifically; it is a fundamental property of Linux’s trust model. AppArmor and SELinux provide policy-based controls over what processes can do, but they operate differently from a user-facing per-process firewall prompt.

For most users running desktop Linux, this gap is not a practical concern. The threat model for a developer’s workstation does not usually include sophisticated binary-spoofing malware. But it is worth naming when comparing the two products, because the macOS version is making a stronger security guarantee.

OpenSnitch and Portmaster Are Already Here

The honest question the HackerNews thread asks is: what does Little Snitch for Linux add that OpenSnitch does not already provide? OpenSnitch is actively maintained, free, GPLv3, and has been shipping eBPF-based process attribution since version 1.6. It has a Qt-based GUI, a gRPC daemon (opensnitchd), per-process and per-user rules, and a statistics view. It is a real, working product.

Portmaster takes a different angle: it bundles DNS-based filtering, threat intelligence feeds, and its own privacy network (SPN) alongside the per-process firewall. The core is AGPLv3 and free; the SPN is a paid feature. It is closer in scope to a privacy suite than a focused firewall tool.

What Little Snitch historically brought to macOS was polish: a network monitor visualization that shows live per-process bandwidth and connection graphs, a rules interface that is genuinely pleasant to use, and reliability that accrued from years of iteration on a single platform. Whether that level of refinement translates to the Linux version is an open question that the product page alone cannot answer. The proof will be in how it handles edge cases: connections made before the daemon starts, applications that open dozens of connections per second, DNS resolution flows, and the specific weirdness of systemd-resolved and snap-confined processes.

The Notification Problem on Wayland

One underappreciated challenge in shipping a per-process connection prompt on modern Linux is Wayland. The Little Snitch prompt model requires interrupting a connection to ask the user a question, which means displaying a window with focus, ideally above other windows, on whichever monitor the user is looking at. On X11 this was straightforward; applications could raise and focus windows freely. On Wayland, the compositor controls focus and most compositors do not allow arbitrary applications to steal focus or guarantee layer-shell positioning.

The established approach is to use the xdg-desktop-portal notification interface, which routes through the compositor or notification daemon. This works for informational notifications but is less suited to blocking decision prompts that need an immediate response before the connection times out. How Little Snitch handles this on GNOME versus KDE versus other compositors will be a key part of the real-world experience.

What This Arrival Means

Objective Development building a Linux version of Little Snitch is a meaningful signal even before you use the product. It reflects that Linux desktop adoption has reached a level where the company sees a viable market, and it brings serious commercial resources to a problem that has mostly been addressed by enthusiast-driven open source projects. Competition tends to improve everything in this space: OpenSnitch and Portmaster will respond, documentation will improve, and the overall category becomes more legible to users who want to know what their machines are actually doing on the network.

The eBPF infrastructure that makes this possible has been production-grade for several kernel generations now. The tooling around it, including libbpf and the CO-RE (compile once, run everywhere) approach to portable eBPF programs, has matured enough that writing a robust userspace firewall without a custom kernel module is tractable work. The hard problem was never the kernel mechanism; it was building the reliable, low-friction user experience on top of it. That is exactly what Little Snitch has always been good at solving.