Objective Development announced they are working on a Linux version of Little Snitch, and my first reaction was genuine curiosity about how they would pull it off. Not because Little Snitch is hard to design, but because the platform primitives that make it work cleanly on macOS simply do not exist on Linux in the same form. The product exists since 2001 and has survived three major kernel architecture transitions on the Mac side. Porting it to Linux means rebuilding the interception layer from scratch, on a platform with a much messier network security model.
Understanding why this is interesting requires knowing what Little Snitch actually does under the hood.
How Little Snitch Works on macOS
At its core, Little Snitch intercepts outbound network connections before they are established and asks you whether to allow or deny them, with the connecting application identified by name, code signature, and the specific destination host and port. The UX is simple. The implementation is not.
For years, Little Snitch used a BSD socket filter registered via sflt_register(), a kernel extension API that let it intercept connections at the socket layer with full process context available. When Apple deprecated kernel extensions with macOS Catalina and introduced the Network Extension framework, Objective Development migrated to a NEFilterDataProvider and NEFilterControlProvider architecture: a user-space system extension that receives connection events from the kernel, along with the pid, process path, and code signature of the connecting process, and returns an allow or deny verdict. The process identity comes from Apple’s SecCode APIs, which verify against the code signing infrastructure. Spoofing it is not straightforward.
The kernel-to-userspace handoff is the key piece. macOS provides a first-class mechanism where a network connection can be held pending a verdict from a sandboxed user-space process. The connection waits. The user sees a dialog. The verdict comes back. The connection either proceeds or does not. This is a designed workflow with OS support.
The Linux Problem
Linux has no equivalent. The fundamental issue is that the Linux networking stack does not natively associate sockets with process identities in a way that is accessible at packet-filter time. The association does exist: /proc/net/tcp maps socket inodes to pids, and from there you can walk /proc/<pid>/fd/ to resolve which process owns a given connection. But this lookup happens in a different subsystem from the packet filter, and it is subject to time-of-check/time-of-use races. A process can make a connection, close its socket, and be replaced by another process at the same pid before your firewall daemon finishes the lookup.
The traditional Linux firewall stack, Netfilter, works at the packet level. iptables and its modern replacement nftables can match on IP addresses, ports, protocols, UIDs, GIDs, and cgroup membership. That last one is useful: with systemd and cgroupv2, you can write nftables rules that apply to specific systemd units. But that granularity is per-service, not per-binary, and there is no interactive verdict mechanism. You write rules ahead of time; the kernel enforces them silently.
Netfilter does have NFQUEUE, which lets a userspace daemon receive packets, look up process identity via /proc, prompt a user if needed, and return an ACCEPT or DROP verdict. This is how OpenSnitch works, the closest existing analogue to Little Snitch on Linux. OpenSnitch is a Go rewrite of an older Python project, uses NFQUEUE for interception, has a GTK UI for managing rules, and is actively maintained. It works. It also has the /proc race condition, adds latency to every new connection on the intercepted path, and requires careful tuning to avoid user-space daemon crashes causing network outages. It is not polished in the way that a commercial product can be.
What eBPF Changes
eBPF is the technology that makes Objective Development’s approach tractable in 2025 in a way it was not in 2015.
Specifically, BPF LSM hooks, introduced in Linux 5.7, allow eBPF programs to attach to Linux Security Module hook points including security_socket_connect() and security_socket_bind(). At these hook points, the kernel is still inside the syscall context of the connecting process, so process identity, including pid, binary path, uid, and cgroup membership, is directly available without any /proc lookup. The race condition disappears. You are in the syscall, you know exactly who is calling, and you can return a deny verdict before the connection is established.
Projects like Tetragon, which came out of Cilium/Isovalent, demonstrate this model at scale. Tetragon uses BPF LSM and kprobes to observe and enforce per-process security policies including network access restrictions, and it operates in production Kubernetes environments. The mechanics are proven.
For Little Snitch’s use case, BPF LSM hooks provide the capture point. A ring buffer (BPF_MAP_TYPE_RINGBUF) streams connection events to a userspace daemon. The daemon resolves application identity (since /proc/exe is still the mechanism for getting the binary path, but at LSM hook time the process is still alive and the inode is valid), checks against a rule set, and if no rule matches, needs to surface a prompt.
The Interactive Verdict Problem
This is where it gets architecturally complicated. eBPF programs cannot block synchronously waiting for a userspace response. An LSM hook eBPF program must return a verdict immediately. So the deny-by-default-then-allow-after-user-confirms flow that Little Snitch is known for requires a hybrid: the eBPF program blocks connections from unknown processes by default via a BPF map entry, the userspace daemon receives the event, shows the UI prompt, and if the user approves, updates the BPF map to allow future connections from that process. The first connection attempt fails or times out; subsequent ones succeed after the rule is written.
This is a workable design but it has implications for UX. On macOS, Little Snitch can hold the first connection attempt open while the user decides. The connection does not fail; it waits. On Linux, holding a connection in a paused state pending user input is not something BPF LSM hooks support out of the box. NFQUEUE can do it, so a hybrid approach using BPF LSM for detection plus NFQUEUE for the specific interactive prompt flow is possible, but it is more complex than either mechanism alone.
There are also the distribution and privilege problems. eBPF programs that use BPF LSM require CAP_BPF and CAP_PERFMON at minimum, and on many distributions these are root-only capabilities. Packaging a BPF-based daemon so it works across Debian, Fedora, Arch, and whatever else users are running, with correct privilege handling and without breaking anything on kernel updates, is non-trivial engineering.
And then there is the GUI question. macOS has one display system, one primary GUI toolkit, and a well-understood model for system-level alert dialogs that appear over whatever is in the foreground. Linux has X11, Wayland (with multiple compositors), GTK, Qt, and no standard mechanism for a background daemon to raise an urgent, always-on-top prompt that works regardless of the desktop environment. Objective Development will need to pick their battles here, almost certainly starting with the most common setups (GNOME on Wayland/X11) and expanding from there.
What This Means
For Linux desktop users who care about outbound privacy, this is worth watching. OpenSnitch fills the gap today and is worth running if you want any per-application visibility into what your system is phoning home to. But a commercial product with Objective Development’s history of polish and maintenance commitment would be meaningfully different.
The deeper story is that eBPF has made Linux competitive for this class of tooling. Falco, Tetragon, and commercial EDR vendors have already validated the eBPF approach for security observability and enforcement. Little Snitch for Linux will, by necessity, be built on the same foundation. The platform primitives are there. The product-level engineering to turn them into something as usable as the macOS version is the remaining work, and that is exactly the kind of work that Objective Development has been doing for 24 years.