littlesnitch-linux: the open source eBPF layer behind Little Snitch for Linux

Three crates and a webroot, not the whole product

This repository contains the Open Source part of Little Snitch for Linux, and it is worth being precise about what that means, because the licensing is split. The repository holds four things. The Rust crate named ebpf contains all eBPF programs attached to the Linux kernel. The Rust crate named common contains all types and functions shared between kernel and user space. The Rust crate named demo-runner is a user space program that loads the eBPF programs into the kernel and demonstrates how to share data with them through eBPF maps, loading two blocklists for demonstration, blocked_hosts.txt and blocked_domains.txt, which sit at the top level of the tree next to it. The fourth piece, webroot, is the JavaScript web UI of Little Snitch for Linux. All of that code is Open Source under the GNU General Public License Version 2, and it is part of Little Snitch for Linux, a free product by Objective Development. The full product also includes proprietary code that is not in this repository, and the README is explicit that although the product is free to use, that proprietary portion is not Open Source. If you are looking for a complete Linux firewall product you can read end to end, this is not it.

The demo-runner is a worked example of the eBPF map data path

The demo-runner crate is the most useful thing in the repository for a developer, because it is a working example rather than a library surface. It loads the eBPF programs into the kernel and shows how to share data with those programs via eBPF maps, and it demonstrates that with two plain text blocklists at the root of the repository, one for hosts and one for domains. That means the filtering logic is observable without installing anything else: you can see the blocklists being consulted, you can see what crosses the boundary between kernel space and user space, and you can change the input to see the behaviour change. The Cargo workspace structure reflects the split, with demo-runner, common and ebpf listed as members and default-members set to demo-runner and common, so a plain cargo build at the root does not attempt to build the kernel-side crate on its own.

The nightly toolchain is pinned because the verifier is unforgiving

The README is candid about the fragility here. eBPF is a bit fragile, and the kernel verifier may reject the program after changes in the verifier itself, in the Rust compiler or in bpf-linker. The nightly toolchain used for the eBPF build is therefore pinned in ebpf/rust-toolchain.toml, and the build scripts of the crates embedding the eBPF program, which the README names as demo-runner and the daemon, read the pin from there and pass it to rustup run explicitly. That design is the whole reason the build works at all: instead of using whatever nightly your machine happens to have, the build script selects the one version the code was written against. The README states the tested envelope precisely, saying the code is known to pass the verifier on Linux kernels 6.12 to 7.2.0 when compiled with the pinned nightly-2026-07-07 and bpf-linker 0.10.3, and that other versions may or may not work. That is a narrow window for anyone running an unusual kernel.

Four prerequisites, and the aya commit is pinned too

The prerequisites list is short and specific. First, a stable Rust toolchain installed with rustup toolchain install stable. Second, the pinned nightly toolchain for the eBPF build, for example rustup toolchain install nightly-2026-07-07 --component rust-src, with ebpf/rust-toolchain.toml holding the currently pinned version. Third, bpf-linker, installed with cargo install bpf-linker --locked, where version 0.10.3 is known to work. Fourth, the clang C and C++ compiler. The dependency pinning extends beyond the toolchain. The Cargo workspace pulls in aya, aya-build, aya-ebpf and aya-log from git rather than from a registry, each pinned to the same commit, 4fbce44b6a49dd189a7a3520c66db45baf3832ea, with default features turned off for the aya crates. The comment in the manifest says that particular commit is known to work and that eBPF is somewhat fragile, so you should stick with it until a newer one is proven to work. Two different pinning mechanisms therefore guard the build, and both exist for the same reason.

Building is a normal cargo workflow once the toolchains are in place

Once the prerequisites are satisfied, the build is unremarkable. The README says to use cargo build, cargo check and the other cargo commands as normal, and to run the program with a release build:

cargo run --release

The important detail is that you do not build the eBPF programs by hand. Cargo build scripts build the eBPF programs automatically and include them in the binary. That is what makes the release profile block in the workspace manifest worth noticing, where the ebpf package gets debug level 2 and codegen-units set to 1. The rest of the repository layout supports the same story. There is a Cargo.lock, so dependency versions are recorded, a .cargo directory for cargo configuration, a rustfmt.toml for formatting, and a Cargo workspace with resolver version 2. The workspace package block also declares edition 2024, so a toolchain older than what that edition requires will not build this.

Two licence statements that do not agree, and why that matters

The licence field on the repository says GPL-2.0, and the README states that all code in this public repository is Open Source and distributed under the GNU General Public License Version 2, with the eBPF code specifically called out as GPL-2 as well. The root of the tree carries LICENSE-GPL2.txt, and the contribution terms say that unless you explicitly state otherwise, any contribution intentionally submitted for inclusion is licensed under the GPL-2 terms with no additional conditions. However, the Cargo manifest is different. The workspace.package block sets license to MIT OR Apache-2.0. That inconsistency is in the repository itself rather than something introduced by paraphrase, and it matters if you are vendoring crates from this workspace into your own build, because Cargo will read the manifest value while a reader of the README will read the GPL-2 statement. Whichever governs, the safest position is to treat the public repository as GPL-2 and check the manifest before redistributing any crate individually. This is not legal advice, it is a note about where the ambiguity sits.

The web UI is the JavaScript front end of a product you do not get here

The webroot directory holds the JavaScript web UI of Little Snitch for Linux, and it is the part of this repository with the least standalone use. The user interface for the product is written against the daemon that loads the eBPF programs and enforces the filtering, and that daemon is proprietary and not in this repository. You can read the front end, and you can learn the shape of the interface, but running it standalone would mean reimplementing the parts that are not published. The releases tell the same story. The tags are named releases/1.1.0 for Little Snitch for Linux 1.1.0, with releases/1.1.0-pre6 and releases/1.1.0-pre5 as prereleases, all published in the first half of July 2026, and the last push to the repository was on 2026-07-13. So the open source layer is versioned in step with the product releases rather than on its own schedule, which is the pattern you would expect when the open and proprietary halves ship together.

Editorial conclusion

littlesnitch-linux suits an engineer who wants to read or adapt the eBPF programs that implement Little Snitch's network filtering on Linux, and who is prepared to respect a pinned toolchain and a pinned aya commit rather than track the latest Rust nightly. It does not suit someone who expects the complete product, because the proprietary portion is not in this repository and the web UI here only makes sense next to the daemon that loads these programs. Before you build it, read ebpf/rust-toolchain.toml to get the exact pinned nightly, install bpf-linker at the version the README names, and check that your kernel falls in the 6.12 to 7.2.0 range the code is known to pass the verifier on.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. obdev/littlesnitch-linux on GitHub
4. README
5. Releases