LittleSnitch Comes to Linux, and the Kernel Problem It Had to Solve

For anyone who has spent time on macOS, LittleSnitch needs no introduction. Objective Development’s network monitor has been intercepting outbound connections and prompting users to approve or deny them since 2004. It sits between your applications and the network and makes every connection legible: that telemetry ping your text editor just attempted, the analytics call hidden inside your PDF viewer, the update check your IDE fires on startup. You see it, you decide.

Now ObjDev is bringing it to Linux, and that announcement generated significant discussion on Hacker News. The surface reaction is “finally.” The more interesting reaction is: how, exactly?

Why This Is Harder Than It Sounds on Linux

On macOS, Apple provides the Network Extension API, specifically the NEFilterDataProvider and NEFilterFlow abstractions, introduced in macOS 10.15 as the kext-free replacement for what LittleSnitch previously did with kernel extensions. A NEFilterFlow carries the full connection context: source and destination, the responsible process (complete with its app bundle path and code signing identity), and a clean approve/deny callback. The kernel hands you structured, trustworthy data about who is connecting and where.

Linux has no equivalent single API. There is no NEFilterFlow. There is no “responsible process” concept surfaced through a standard framework. What Linux does have is a collection of kernel subsystems that, when assembled carefully, can approximate the same capability. The assembly is the hard part.

The oldest approach, and the one that the existing open-source alternative OpenSnitch uses, is NFQUEUE (Netfilter Queue). The idea is straightforward: you configure an iptables or nftables rule to redirect packets matching some criteria into a userspace queue, your daemon reads from that queue, makes a decision, and issues a verdict back to the kernel. The connection is held in limbo while the daemon works.

The problem is process attribution. When NFQUEUE delivers a packet to your daemon, it gives you network-layer information: IP addresses, ports, protocol. It does not tell you which process sent it. To find that out, you have to correlate the connection against /proc/net/tcp (or /proc/net/tcp6, /proc/net/udp, etc.) to find the socket inode number, then walk every process’s file descriptor directory under /proc/[pid]/fd/ looking for a symlink pointing to socket:[inode]. This gives you the PID.

The race condition here is real. A short-lived process can open a connection, have its packet queued, and exit before your daemon finishes the /proc walk. You find no matching process, and you either fail closed (block) or fail open (allow) based on whatever default you configure. OpenSnitch manages this reasonably well in practice, but it is a fundamentally racy approach to process attribution.

There is also overhead. Every packet that hits your NFQUEUE rule crosses the kernel-userspace boundary. For high-throughput connections, this serializes traffic through your daemon and the associated syscall overhead. OpenSnitch mitigates this by only inspecting the first packet of a connection (once you have made a decision, you can connmark the flow and bypass the queue for subsequent packets), but the initial interception still adds latency to every new connection.

The eBPF Path

A more modern approach uses eBPF, specifically socket-level hooks rather than packet-level interception. Linux exposes eBPF attachment points at BPF_PROG_TYPE_CGROUP_SOCK_ADDR (for intercepting connect() and bind() calls on sockets associated with a cgroup), BPF_PROG_TYPE_SOCK_OPS (for connection lifecycle events), and LSM hooks via BPF LSM (available since Linux 5.7), which can attach to security_socket_connect and related entry points at the exact moment a syscall is made.

The cgroup-based approach is particularly well-suited to this problem because cgroups are how Linux groups processes anyway. A cgroup sock_addr program fires when a process in that cgroup calls connect(), before the connection is established. Process context is available directly inside the BPF program through helpers like bpf_get_current_pid_tgid() and bpf_get_current_comm(), along with cgroup identifiers. No NFQUEUE, no cross-boundary /proc polling, no race on process exit.

The limitation is that BPF programs cannot block on userspace decisions, and they obviously cannot pop up a UI. The practical architecture is to have the BPF program communicate with a userspace daemon through a BPF ring buffer or perf event buffer. The daemon makes the real policy decision and writes it back into a BPF map. For the common case (a previously seen connection with a cached rule), the BPF program resolves the verdict without userspace involvement at all. For new connections requiring user approval, the daemon handles it, which still requires some mechanism to hold the connection pending that decision.

Portmaster by Safing, the other notable commercial entrant in this space, has been evolving toward this eBPF-based architecture after starting with a kernel module. Their trajectory over the past couple of years gives some indication of what production-grade per-application network control looks like on modern kernels.

What Objective Development Brings to the Table

ObjDev has been building network monitoring software for over two decades. They navigated the transition from kernel extensions to Network Extensions on macOS, which is its own story about adapting a security product to a fundamentally changed kernel API surface. They understand the problem domain at a level that most tools built by individuals working in their spare time do not.

OpenSnitch is genuinely useful and has improved considerably over the years, but it carries the marks of its origin: a concept designed for macOS’s clean API, retooled for Linux’s less clean substrate. The UI is functional. Rule management works, but it requires understanding the underlying model in ways that should be implementation details. These are not complaints so much as observations about what happens when capable developers build something complex without a dedicated product team around it.

A commercial product from a company with ObjDev’s track record suggests investment in the parts of the problem that are boring to solve but important to get right: stable behavior across the fragmented landscape of Linux distributions and kernel versions, sensible defaults that protect without overwhelming users with prompts, rule persistence that survives system updates cleanly, and, ideally, some form of process identity verification that goes beyond trusting a path string that an attacker could replace.

Why It Matters for Linux Desktop Security

The conversation around Linux desktop security tends to focus on what the kernel enforces by default, on the theoretical correctness of the permission model, on SELinux and AppArmor profiles and what they prevent. What gets less attention is the outbound connection question: the software you install, even software you trust, talks to the network constantly, often in ways that are not documented and that you did not explicitly authorize. Closed-source applications phone home. Open-source applications have optional telemetry enabled by default. Libraries inside applications open connections that the application itself may not be fully aware of.

Application firewalls are not a replacement for proper system hardening, but they are a useful complement. They make the network activity of your installed software observable and, where you want it, controllable. That kind of visibility has been available on macOS as a polished, well-maintained commercial product for years. Linux has had working but rough alternatives.

LittleSnitch entering the Linux space raises the baseline for what a per-application firewall on this platform looks and feels like. That is good for users, and it gives the existing open-source tools a concrete target to compare against. Competition in a security tool category, commercial or otherwise, tends to benefit everyone who cares about understanding what their machine is actually doing on the network.