On this page
Runtime dependencies
The static executable, embedded SQLite C and host tools required by each input and firewall path.
One executable, explicit dependencies
fail2zig 0.4.0 ships one static executable per architecture. Zig application code embeds pinned SQLite C and links musl. Daemon, administration, rule testing and migration share that executable. No Python runtime, SQLite server, SQLite CLI or shared SQLite library is required for product operation.
Static linkage packages code inside an artifact; it does not remove that code from the dependency or security boundary. SQLite updates require a new fail2zig build, just as changes to the Zig application do.
Requirements by path
| Path | Required host facilities |
|---|---|
| File input | Read/search access to configured files and directories; Linux file notification and I/O interfaces. |
| Journal input | journald and journalctl, plus admitted journal origins. |
| nftables enforcement | Linux nf_tables and CAP_NET_ADMIN; direct netlink, no nft CLI or libnftnl. |
| iptables enforcement | The host iptables tool and required kernel support. |
| ipset enforcement | Both ipset and iptables tools and required kernel support. |
| Durable state | Writable persistent storage owned by the service UID. |
| Named timezones | The selected timezone data under timezone_root. |
| Shipped service | systemd and the unit’s required capabilities and filesystem access. |
Host tools are invoked with structured argument arrays, not shell templates.
Attacker-provided log bytes are never evaluated as commands. global.firewall
can select a backend explicitly; a forced backend does not fall back silently.
Why direct netlink for nftables
The nftables backend constructs typed messages and communicates with Linux directly. It does not depend on executable discovery or on interpreting the nft command’s output. Enforcement intent is durable before dispatch; owned kernel readback establishes installed protection afterwards.
This property belongs to the nftables path. Journal input and iptables/ipset have the host-tool requirements above, even though the application is statically linked. See enforcement.
Privileges remain part of the contract
The shipped unit runs as the non-login fail2zig account, retaining
CAP_NET_ADMIN, CAP_NET_RAW and CAP_DAC_READ_SEARCH. NET_RAW supports the
iptables ipset extension and permits raw IP sockets; AF_PACKET is excluded.
HTTP shares the same process and capabilities. The dedicated UID does not make
the daemon unprivileged or isolate its HTTP parser from enforcement authority.
Configuration and executables remain administrator-owned. Native state belongs to the service UID. Monitoring-group members can read status; only root or the daemon UID can mutate protection.
Platform qualification
Five Linux artifacts are published: x86_64, ARM64, ARM hard float, MIPS32r2 big endian and MIPS32r2 little endian. Selected live qualification used Debian 13 x86_64 before the version-only change from the unpublished 0.3.1 candidate. The rebuilt 0.4.0 artifacts passed native/emulated command checks.
Non-x86 targets have cross-build, static-inspection and QEMU smoke evidence; real-hardware/kernel enforcement is untested. Ubuntu is untested. Static musl linkage alone does not establish support on every distribution, router or container. Firewall effects are limited to the daemon’s current network namespace; moving it between namespaces through custom selectors or service overrides is unsupported.
See artifact verification and the trusted computing base.