Skip to content

fix(snitchwatch): keep the firewall up when the bridge gRPC socket stops - #86

Closed
bearyjd wants to merge 2 commits into
build/snitchwatch-r8-repinfrom
fix/snitchwatch-bridge-socket-wants
Closed

bearyjd wants to merge 2 commits into
build/snitchwatch-r8-repinfrom
fix/snitchwatch-bridge-socket-wants

Conversation

@bearyjd

@bearyjd bearyjd commented Oct 8, 2026 •

Copy link
Copy Markdown
Owner

Stacked on #85. This keeps the firewall up when the system bridge's gRPC socket is stopped. The owner made the decision on 2026-10-08.

Problem

opensnitch.service's system-bridge drop-in had Requires=snitchwatch-system-bridge-grpc.socket. On the r8 VM, systemctl stop of that socket also stopped opensnitchd, and it stayed down after the socket came back. Nothing was being enforced: there were 0 NFQUEUE rules and a deny-by-default connection passed. Only root can trigger this, and it has been there since #76.

Change

  • The drop-in now uses Wants= with the same After=. At boot the socket is still pulled in and ordered before the daemon. Stopping it no longer stops the daemon, which falls back to its default action while no UI is connected (stock OpenSnitch behaviour without a GUI).
  • The build verifier (byte-pinned drop-in), the readiness helper, the boot check and the tests now expect Wants=.
  • The readiness helper and the boot check also refuse the socket in Requires=, Requisite=, BindsTo= or PartOf=, so an edit to the main unit can't bring the stop back. A new test covers each of the four, and it fails if the check is removed.
  • Docs: the research note records the decision. It also records the owner's confirmation that the system variant's two-action notification allowlist (CHANGE_RULE/DELETE_RULE) is policy.

Test plan

  • tests/test-snitchwatch-system.py (61), tests/test-snitchwatch-system.sh, tests/test-snitchwatch-image-build.py, tests/test-snitchwatch-image-build-daemon.py pass
  • shellcheck tests/boot-check.sh; just check
  • Independent code review: APPROVE. Its MEDIUM (no negative assertion) and LOW (stale doc line) are both fixed in bd07020.
  • CI green
  • r10 VM: PASS (R10-VM-ACCEPTANCE-RESULT.json):
    • stop and start the gRPC socket; opensnitchd stays active, its NFQUEUE rules stay, and it reconnects to the bridge without a restart;
    • the readiness helper passes on the real unit (systemctl show --all lists the empty dependency properties)

opensnitch.service's system-bridge drop-in used Requires= on
snitchwatch-system-bridge-grpc.socket, so stopping the socket also stopped
the firewall daemon and it stayed down after the socket came back (r8 VM:
0 NFQUEUE rules, a deny-default connection passed). Use Wants= with the same
After= ordering instead: boot still pulls the socket in first, but losing it
leaves the daemon running on its default action. The build verifier, the
readiness helper, the boot check and the tests now expect Wants=.
The readiness helper and boot check now also refuse the socket in
opensnitch.service's Requires=, Requisite=, BindsTo= or PartOf=, so a
change to the main unit can't reintroduce the stop propagation the Wants=
drop-in removed. Record the owner's confirmation that the two-action
notification allowlist is policy.
@bearyjd

bearyjd commented Oct 9, 2026

Copy link
Copy Markdown
Owner Author

Included via #92 (merge commit af32644): this PR's commits are in main as part of the stacked merge; the r12 image was VM-accepted at 21adea3.

@bearyjd bearyjd closed this Oct 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant