Hi everyone,
I am an undergraduate CS student working on Linux network security. I am looking for an architectural feedback on a project I’ve been building: TransparentTorProxy (TTP).
It’s a wrapper around Tor crash-safe and volatile. TTP v0.4.6 is now officially strictly systemd-native to handle privilege dropping and zero-leak routing. I would love to know if there are blind spots in this architecture.
Core Architectural Choices:
- Application Exclusion (cgroups v2): The ttp bypass command uses systemd-run to launch apps inside a transient scope (ttp-bypass.slice), which is pre-authorized via an nftables rule (socket cgroupv2 level 1 “ttp-bypass.slice” accept). This de-escalates privileges securely and ensures the process is born already inside the bypassed cgroup, eliminating race conditions.
- Polkit Privilege Dropping: The background watchdog daemon runs as an unprivileged system user (ttp-watchdog) with only CAP_NET_ADMIN. To heal a crashed Tor service, it uses a custom Polkit rule to authorize the restart via D-Bus, avoiding CAP_SYS_ADMIN entirely.
- Graceful teardown: When stopping the proxy, TTP injects temporary TCP Reset rules and flushes the Netfilter connection tracking table before removing the firewall. This actively kills pending local connections before they can leak in cleartext.
- systemd-resolved hijacking: To prevent D-Bus/NSS bypasses, TTP writes a volatile drop-in to /run/systemd/resolved.conf.d/ forcing all domains to Tor’s DNSPort, backed by a fail-closed firewall rule. Since it resides in /run/, the host DNS state naturally evaporates and restores upon reboot.
The Ask:
Are there edge cases in my use of cgroups v2 or Polkit that I am missing? Are there known vulnerabilities in this specific systemd interaction pattern?
The source code and Architecture Decisions Records (ADRs) are available here:
Thank you in advance for your time and expertise.