Recognition: unknown
ProcRoute: Process-Scoped Authorization of Split-Tunnel Routes
Pith reviewed 2026-05-10 08:10 UTC · model grok-4.3
The pith
ProcRoute restricts split-tunnel internal routes to explicitly authorized processes.
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
Core claim
ProcRoute models route access as an access-control problem: application identities are principals, destination prefixes with port and protocol constraints are resources, and a total, default-deny decision function mediates every connect() and UDP sendmsg() to an internal destination. Processes without a grant retain external access but are denied internal routes under our threat model.
What carries the argument
The process-scoped authorization mechanism that intercepts connect() and UDP sendmsg() calls using cgroup v2 and eBPF socket-address hooks to enforce per-process grants for internal routes.
If this is right
- Internal routes become usable only by processes that receive explicit authorization grants.
- Unauthorized processes keep full external network access while being blocked from internal destinations.
- The authorization decision applies to every connection attempt, supporting dynamic policy changes with sub-millisecond revocation.
- Performance remains close to the unmodified VPN baseline even when enforcing thousands of route prefixes.
Where Pith is reading between the lines
- The mediation approach could extend to other types of resource access that currently rely on device-level policies.
- Integrating similar hooks might help enforce application-specific network policies in containerized environments.
- Verifying the hooks across multiple Linux distributions would strengthen confidence in the completeness of the mediation.
Load-bearing premise
That the cgroup v2 and eBPF socket-address hooks cannot be bypassed by unprivileged processes attempting to reach internal destinations.
What would settle it
Finding an unprivileged process that succeeds in connecting to an internal destination without an authorization grant, despite the hooks being active, would show the mediation is incomplete.
Figures
read the original abstract
In most split-tunnel VPN/ZTNA deployments, installing an internal route authorizes the entire device, not a specific application, to use it. An unprivileged malicious process can therefore reach internal services by reusing routes intended for corporate applications. We present ProcRoute, a system that restricts internal-route access to explicitly authorized applications. ProcRoute models route access as an access-control problem: application identities are principals, destination prefixes with port and protocol constraints are resources, and a total, default-deny decision function mediates every connect() and UDP sendmsg() to an internal destination. Processes without a grant retain external access but are denied internal routes under our threat model. We describe ProcRoute's formal model, a Linux prototype built on cgroup v2 and eBPF socket-address hooks, and two complementary evaluations. In a two-machine WireGuard deployment, ProcRoute matches the WireGuard baseline and 13% faster than an nftables cgroup-matching configuration, with a p50 connect latency of 93 $\mu$s (+3.6 $\mu$s over baseline), flat policy scaling to 5,000 prefixes, and sub-millisecond revocation. Single-machine loopback microbenchmarks confirm low hook overhead: 2.7 $\mu$s on the internal-allow path, 82/82 unauthorized pivot attempts blocked, and zero transient allows across 1.2 million connection attempts during policy reload.
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The paper presents ProcRoute, a system that restricts internal-route access in split-tunnel VPN/ZTNA deployments to explicitly authorized applications by modeling route access as an access-control problem (principals = application identities, resources = destination prefixes with port/protocol constraints). A default-deny decision function mediates every connect() and UDP sendmsg() to internal destinations via a Linux prototype built on cgroup v2 and eBPF socket-address hooks. Processes without grants retain external access but are denied internal routes. Evaluations in a two-machine WireGuard setup show performance matching baseline (p50 connect latency 93 μs, +3.6 μs overhead), flat scaling to 5,000 prefixes, sub-millisecond revocation, and 82/82 blocked unauthorized pivots with zero transient allows in 1.2M loopback attempts.
Significance. If the mediation is complete, ProcRoute addresses a practical security gap in current split-tunnel deployments where internal routes authorize the entire device. The concrete latency, scaling, and blocking results, combined with the formal model, indicate a deployable improvement for ZTNA security with negligible performance cost.
major comments (2)
- [Prototype Implementation and Threat Model] The central claim that unprivileged processes are denied internal routes under the threat model depends on cgroup v2 + eBPF socket-address hooks providing complete, unbypassable mediation of all connect() and UDP sendmsg() paths. The prototype description and evaluation (82/82 blocked pivots, zero transient allows) only cover standard socket calls; potential bypasses via AF_PACKET/SOCK_RAW, io_uring, direct syscalls, or namespace escapes are not addressed or tested.
- [Evaluation (single-machine loopback microbenchmarks)] Table or microbenchmark results reporting 82/82 blocked pivots and zero transient allows across 1.2 million attempts do not specify the test harness details (e.g., whether it exercises only libc wrappers or all possible syscalls and raw interfaces), leaving the completeness claim unsupported.
minor comments (2)
- [Abstract] The abstract states 'two complementary evaluations' but only details the WireGuard deployment and loopback microbenchmarks; explicitly label and cross-reference the second evaluation in the text.
- [Evaluation] Performance claims include p50 latency but omit higher percentiles, variance, or full distributions; add these for clearer overhead assessment.
Simulated Author's Rebuttal
We thank the referee for the constructive feedback highlighting the importance of clearly defining the threat model and evaluation harness. We address both major comments below by clarifying the scope of our assumptions and committing to revisions that strengthen the manuscript without altering its core contributions.
read point-by-point responses
-
Referee: [Prototype Implementation and Threat Model] The central claim that unprivileged processes are denied internal routes under the threat model depends on cgroup v2 + eBPF socket-address hooks providing complete, unbypassable mediation of all connect() and UDP sendmsg() paths. The prototype description and evaluation (82/82 blocked pivots, zero transient allows) only cover standard socket calls; potential bypasses via AF_PACKET/SOCK_RAW, io_uring, direct syscalls, or namespace escapes are not addressed or tested.
Authors: We agree that explicit delineation of the threat model is essential. ProcRoute targets unprivileged processes without CAP_NET_RAW or other capabilities needed for raw sockets, io_uring, or namespace escapes; the latter would require root privileges and is therefore outside the stated threat model of an unprivileged malicious process reusing routes. The eBPF hooks intercept the standard connect() and sendmsg() paths used by applications to reach internal destinations. The 82/82 blocked pivots and zero transient allows were measured on these paths. We will revise the manuscript to explicitly state these assumptions in the threat model section and note that raw interfaces and io_uring fall outside the model. We will also add a brief discussion of why namespace escapes are excluded. This constitutes a partial revision focused on clarification rather than new experiments. revision: partial
-
Referee: [Evaluation (single-machine loopback microbenchmarks)] Table or microbenchmark results reporting 82/82 blocked pivots and zero transient allows across 1.2 million attempts do not specify the test harness details (e.g., whether it exercises only libc wrappers or all possible syscalls and raw interfaces), leaving the completeness claim unsupported.
Authors: We acknowledge the need for greater transparency on the test harness. The microbenchmarks used a custom program that exercised both libc wrappers and direct syscall invocations of connect() and sendmsg() to internal destinations, with policy reloads interleaved across the 1.2 million attempts. Raw sockets and io_uring were not included because they require capabilities excluded by the threat model. We will revise the evaluation section to describe the harness in detail, including the mix of wrapper and direct-syscall paths tested, and to reiterate that completeness is claimed only within the defined threat model. This revision will be incorporated in the next version. revision: yes
Circularity Check
No significant circularity: systems implementation with empirical evaluation
full rationale
The paper presents a Linux prototype built on cgroup v2 and eBPF socket-address hooks, a formal model of route access as an access-control problem, and two complementary evaluations (WireGuard deployment benchmarks and single-machine microbenchmarks with 82/82 blocked pivots and zero transient allows). No mathematical derivations, fitted parameters, predictions, self-citations, or ansatzes appear in the provided text. The central claim is supported by described implementation details and benchmark results rather than reducing to its own inputs by construction. This is a standard honest finding for an implementation and benchmarking paper.
Axiom & Free-Parameter Ledger
axioms (1)
- domain assumption Linux cgroup v2 and eBPF socket-address hooks can mediate every connect() and UDP sendmsg() to internal destinations without being bypassed by unprivileged processes.
Reference graph
Works this paper leans on
-
[1]
Jonathan Anderson, Robert N. M. Watson, and Kris Kennaway. 2010. Capsicum: Practical Capabilities for UNIX. InProc. 19th USENIX Security Symposium. 29–45
2010
-
[2]
Canonical Ltd. 2024. AppArmor. https://apparmor.net
2024
-
[3]
Isovalent. 2024. Cilium: eBPF-based Networking, Observability, and Security. https://cilium.io
2024
-
[4]
Isovalent. 2024. Tetragon: eBPF-based Security Observability and Runtime En- forcement. https://tetragon.io
2024
-
[5]
Joint Task Force. 2020.Security and Privacy Controls for Information Systems and Organizations. Technical Report SP 800-53 Rev. 5. NIST. doi:10.6028/NIST.SP.800- 53r5
-
[6]
Peter Loscocco and Stephen Smalley. 2001. Integrating Flexible Support for Security Policies into the Linux Operating System. InProc. USENIX Annual Technical Conference (FREENIX Track). 29–42
2001
-
[7]
MITRE. 2024. Lateral Movement – MITRE ATT&CK. https://attack.mitre.org/ tactics/TA0008/
2024
-
[8]
2016.Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security
National Institute of Standards and Technology. 2016.Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security. Technical Report SP 800-46 Rev. 2. NIST. doi:10.6028/NIST.SP.800-46r2
-
[9]
2021.Selecting and Hardening Remote Access VPN Solutions
National Security Agency and Cybersecurity and Infrastructure Security Agency. 2021.Selecting and Hardening Remote Access VPN Solutions. Technical Report. NSA/CISA. U/OO/184997-21
2021
-
[10]
netfilter project. 2024. Matching packet metainformation — nftables wiki. https:// wiki.nftables.org/wiki-nftables/index.php/Matching_packet_metainformation
2024
-
[11]
Scott Rose, Oliver Borchert, Stu Mitchell, and Sean Connelly. 2020.Zero Trust Architecture. Technical Report SP 800-207. NIST. doi:10.6028/NIST.SP.800-207
-
[12]
Mickaël Salaün. 2017. Landlock: Unprivileged Access Control. InProc. Linux Security Summit
2017
-
[13]
systemd project. 2024. systemd.resource-control — Resource Control Unit Set- tings. https://www.freedesktop.org/software/systemd/man/systemd.resource- control.html. Documents IPAddressAllow= and IPAddressDeny= directives; available since systemd 235
2024
-
[14]
The Linux Kernel Documentation. 2024. BPF cgroup Programs. https://docs. kernel.org/bpf/
2024
-
[15]
The Linux Kernel Documentation. 2024. Control Group v2. https://docs.kernel. org/admin-guide/cgroup-v2.html
2024
-
[16]
The Linux Kernel Documentation. 2024. Control Group v2 — Delegation. https: //docs.kernel.org/admin-guide/cgroup-v2.html#delegation
2024
-
[17]
The Linux Kernel Documentation. 2024. Seccomp BPF (SECure COMPuting with filters). https://docs.kernel.org/userspace-api/seccomp_filter.html
2024
-
[18]
Rory Ward and Betsy Beyer. 2014. BeyondCorp: A New Approach to Enterprise Security. In;login: The USENIX Magazine, Vol. 39. 6–11
2014
-
[19]
Avishai Wool. 2004. A Quantitative Study of Firewall Configuration Errors. Computer37, 6 (2004), 62–67. doi:10.1109/MC.2004.2
-
[20]
Avishai Wool. 2010. Trends in Firewall Configuration Errors: Measuring the Holes in Swiss Cheese.IEEE Internet Computing14, 4 (2010), 58–65. doi:10.1109/ MIC.2010.29 Table 6: TCP connect() latency (µs). Δp50 = condition − base- line. Condition p50Δp50 p90 p99 Baseline 22.9 — 24.8 32.6 External-miss 24.7 1.8 27.1 35.1 Internal-allow 25.6 2.7 27.2 34.9 Tabl...
2010
discussion (0)
Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.