pith. machine review for the scientific record. sign in

arxiv: 2604.16080 · v1 · submitted 2026-04-17 · 💻 cs.CR

Recognition: unknown

ProcRoute: Process-Scoped Authorization of Split-Tunnel Routes

Authors on Pith no claims yet

Pith reviewed 2026-05-10 08:10 UTC · model grok-4.3

classification 💻 cs.CR
keywords split-tunnel VPNprocess authorizationroute access controleBPF hookscgroup v2zero trust network accessper-process policy
0
0 comments X

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.

The paper establishes that internal route access in split-tunnel VPNs should be decided per process rather than for the whole device. This prevents unprivileged malicious processes from reaching internal services by reusing routes installed for corporate applications. ProcRoute treats the problem as access control, with processes as principals and internal destinations as resources, using a default-deny policy on every socket call. The Linux prototype demonstrates that this can be done with low overhead using existing kernel hooks.

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

These are editorial extensions of the paper, not claims the author makes directly.

  • 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

Figures reproduced from arXiv: 2604.16080 by Arul Thileeban Sagayam.

Figure 1
Figure 1. Figure 1: ProcRoute enforcement architecture: controller, BPF hooks, maps, and audit path. [PITH_FULL_IMAGE:figures/full_fig_p007_1.png] view at source ↗
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.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

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)
  1. [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.
  2. [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)
  1. [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.
  2. [Evaluation] Performance claims include p50 latency but omit higher percentiles, variance, or full distributions; add these for clearer overhead assessment.

Simulated Author's Rebuttal

2 responses · 0 unresolved

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
  1. 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

  2. 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

0 steps flagged

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

0 free parameters · 1 axioms · 0 invented entities

The central claim rests on the assumption that Linux kernel features can enforce the policy without bypass and that the described threat model accurately captures real-world attacker capabilities.

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.
    The prototype and security claims depend on this kernel behavior holding under the stated threat model.

pith-pipeline@v0.9.0 · 5542 in / 1304 out tokens · 42507 ms · 2026-05-10T08:10:35.140416+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

20 extracted references · 4 canonical work pages

  1. [1]

    Jonathan Anderson, Robert N. M. Watson, and Kris Kennaway. 2010. Capsicum: Practical Capabilities for UNIX. InProc. 19th USENIX Security Symposium. 29–45

  2. [2]

    Canonical Ltd. 2024. AppArmor. https://apparmor.net

  3. [3]

    Isovalent. 2024. Cilium: eBPF-based Networking, Observability, and Security. https://cilium.io

  4. [4]

    Isovalent. 2024. Tetragon: eBPF-based Security Observability and Runtime En- forcement. https://tetragon.io

  5. [5]

    Ross et al

    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. [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

  7. [7]

    MITRE. 2024. Lateral Movement – MITRE ATT&CK. https://attack.mitre.org/ tactics/TA0008/

  8. [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. [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

  10. [10]

    netfilter project. 2024. Matching packet metainformation — nftables wiki. https:// wiki.nftables.org/wiki-nftables/index.php/Matching_packet_metainformation

  11. [11]

    2020.Zero Trust Architecture

    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. [12]

    Mickaël Salaün. 2017. Landlock: Unprivileged Access Control. InProc. Linux Security Summit

  13. [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

  14. [14]

    The Linux Kernel Documentation. 2024. BPF cgroup Programs. https://docs. kernel.org/bpf/

  15. [15]

    The Linux Kernel Documentation. 2024. Control Group v2. https://docs.kernel. org/admin-guide/cgroup-v2.html

  16. [16]

    The Linux Kernel Documentation. 2024. Control Group v2 — Delegation. https: //docs.kernel.org/admin-guide/cgroup-v2.html#delegation

  17. [17]

    The Linux Kernel Documentation. 2024. Seccomp BPF (SECure COMPuting with filters). https://docs.kernel.org/userspace-api/seccomp_filter.html

  18. [18]

    Rory Ward and Betsy Beyer. 2014. BeyondCorp: A New Approach to Enterprise Security. In;login: The USENIX Magazine, Vol. 39. 6–11

  19. [19]

    Avishai Wool. 2004. A Quantitative Study of Firewall Configuration Errors. Computer37, 6 (2004), 62–67. doi:10.1109/MC.2004.2

  20. [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...