Please do not open a public issue for security problems. Report privately via GitHub Security Advisories ("Report a vulnerability" on the repo's Security tab), or contact the maintainers listed on the Strix Advanced Tools organization. We aim to acknowledge within 72 hours.

Strix Talon is a firewall tool: it enumerates network activity and creates rules that change what your machine is allowed to send and receive. A firewall that gets this wrong can do real damage — it can lock you out of your own machine, silently break your existing firewall configuration, or be tricked into running something it shouldn't. Three things therefore drive the whole design:

1. It must not lock you out. No rule Talon creates — least of all the kill-switch — may leave the machine unreachable or unrecoverable. Loopback is always exempt and every change is revertible.
2. It must not clobber your firewall. The user (and their distro) already has a firewall configuration. Talon must only ever add and remove its own rules, and revert must restore the prior state exactly, without touching anything Talon did not create.
3. Its inputs are untrusted. Destination IPs, program paths, and the process/ connection data it enumerates are attacker-influenceable. None of it may become a shell command, and none of it may build a malformed or unintended firewall rule.

Talon is otherwise a local tool. It ships no kernel driver, spawns no shell, uses no dynamic code (eval / exec / pickle / marshal / yaml), and makes no network calls of its own — it only observes the connections other programs make.

1. Enforcement is delegated to the OS firewall — no driver to trust. Talon installs no kernel component: no WFP callout on Windows, no custom netfilter module on Linux. Every rule is translated into the operating system's own firewall — Windows Defender Firewall via netsh advfirewall, Linux via nft. There is no third-party driver in your kernel to sign, trust, or keep patched; you are relying on the same firewall engine your OS already ships.

2. Every rule is namespaced — revert can't clobber your ruleset. On Windows, every rule Talon creates has a name beginning StrixTalon-. On Linux, every rule lives in a private strixtalon nftables table that Talon owns end to end. Because Talon only ever writes inside its own namespace, revert removes only Talon's rules (by prefix on Windows, by dropping the private table on Linux) and can never modify or delete a rule that you or your distribution created.

3. No self-lockout. Loopback (127.0.0.0/8 / ::1) is always exempt from every rule, including the kill-switch — local services and the tool's own operation keep working. The kill-switch blocks outbound traffic except loopback, and with --allow-lan it additionally leaves the local LAN reachable, so turning it on can never sever your ability to manage the machine. Every change Talon makes is revertible in one click / one command.

4. No injection. Every firewall command is built as an argv list and executed without a shell — there is no command string for a hostile value to break out of. Destination addresses are validated with the standard-library ipaddress module before they are ever placed in a rule; a value that is not a valid IP is rejected, never passed through. A program path (Windows per-app block) must resolve to a real file on disk before a rule is built, so a bogus or crafted path can't produce a phantom rule.

5. Least privilege. All visibility is read-only and unprivileged — watching per-app egress, listing connections, and enumerating listening sockets need no elevation. Only rule changes (block, unblock, killswitch, revert) require Administrator/root, because only they modify the OS firewall. On Windows the GUI offers an elevated relaunch via the absolute interpreter path (sys.executable), never a PATH-resolved name, so the elevation prompt can't be hijacked by a planted binary.

• tests/test_talon.py — a self-running test suite (no external tools required, no real firewall rules applied): IP validation and rejection, argv construction for the Windows and Linux rule builders (asserting the StrixTalon- prefix and the private strixtalon table), the loopback-always-exempt invariant, kill-switch rule shape (with and without --allow-lan), new-destination diffing, and the no-injection guarantees. Run:

  python tests/test_talon.py

• No interactive allow/deny prompts in v1. The "allow or deny this new connection" pop-up (Little Snitch's signature interaction) requires a WFP callout driver on Windows / NFQUEUE on Linux to hold a packet while it asks you — exactly the kernel component Talon deliberately does not ship. It is out of scope for v1. Talon v1 delivers live visibility, rule-based OS-firewall blocking, and new-destination alerts, not per-connection interception.
• Per-app blocking is Windows-only. netsh advfirewall can match an outbound rule by program path, so per-app blocking works on Windows. On Linux, nft/iptables cannot natively map a running process to a rule, so on Linux Talon blocks by destination IP instead — and the UI/CLI make that distinction explicit.
• Unsigned Windows build may trip SmartScreen / AV. A firewall tool changes security-sensitive settings, so an unsigned build can be flagged on first run. This is expected; verify the source and choose More info → Run anyway.
• Talon is only as good as the OS firewall. Because enforcement is delegated, blocking is subject to the platform firewall's own behaviour and evaluation order. Talon shows and manages its own rules; it does not override or audit rules created outside its namespace.