PermRust: A Token-based Permission System for Rust

Florian Tschorsch; Lukas Gehring; Sebastian Rehms

REVIEW 3 major objections 4 minor 21 references

PermRust: A Token-based Permission System for Rust

T0 review · 3 major / 4 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read PermRust enforces per-library I/O permissions at compile time, so no safe-Rust function can access a system resource without the right token.

desk verdict A candid concept paper whose central 'no I/O without tokens' guarantee is undermined by its own app_ macro forge and an unprototyped Cargo feature the paper admits breaks under feature unification. read the letter →

arxiv 2506.11701 v1 pith:ZLRESPFF submitted 2025-06-13 cs.PL cs.CR

Lukas Gehring , Sebastian Rehms , Florian Tschorsch This is my paper · ORCID

classification cs.PLcs.CR

keywords capability-basedsecurityRustpermissionssupplychainattackszero-costabstractionaccessmatrixmodeltokentypescompile-timeenforcementCargofeatures

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

PermRust is a proposed permission system that moves access control for system resources from the operating system down to the level of individual Rust libraries. The paper's central claim is that if every I/O function in the standard library demands an unforgeable token argument, and token constructors are kept private, then no safe-Rust function can perform I/O without holding the matching permission. Permissions are declared per package in Cargo.toml and enforced by the compiler as a zero-cost abstraction, with no runtime overhead. If the approach holds, third-party libraries would be unable to secretly access the filesystem, network, or other system resources, which would blunt a class of supply-chain attacks exemplified by Log4Shell. The paper is a concept with a proof-of-concept implementation and explicitly leaves evaluation to future work.

What carries the argument

The central object is the token type, a zero-sized struct with a private field created only inside a trusted token module. It is what makes permissions unforgeable in safe Rust, and because it occupies no memory the entire check is a compile-time, zero-cost abstraction. The argument hangs together through the abstract function tree (the program's call graph obtained by contracting all edges that do not end in a function) and the permission matrix over functions-as-subjects and I/O entry points-as-objects, with the single right 'call'. The type checker is claimed to execute Algorithm 1, checking that every call to an I/O object is permitted and that no callee holds rights its caller lacks, while compiling the program.

What would settle it

Take a project with direct dependency LibB and indirect dependency LibA, where LibA has a file-reading app_read_something generated by the permissions macro. If feature unification enables ReadPerm for LibA while LibB's Cargo.toml declares no ReadPerm, and the project still compiles and performs a file read through LibB's call to LibA's app_ function, then the package-level permission enforcement has been bypassed. That concrete build would falsify the claim that app_ entry points enforce declared permissions.

Watch

Extended reading notes

Core claim

The paper establishes a capability-as-keys design for Rust. Each system resource is guarded by a token type: a zero-sized struct whose field is private, so safe Rust code outside the trusted token module cannot construct it. The standard library is wrapped so that every I/O function takes the corresponding token as an argument; consequently, the only way to call such a function is to possess the token, and the only way to obtain a token is through the app_ entry points, which the permissions macro generates only for the permissions declared in a package's Cargo.toml. To prevent transitive dependencies from minting tokens through app_ functions, the design introduces a Cargo feature called direct-dependency that only the root package can enable; the paper acknowledges this feature does not exist today and would need to be added to Cargo. The paper formalizes the desired property using the access matrix model and the abstract function tree: a program is permission respecting if every call edge to an I/O object carries the 'call' right, and privilege escalation free if no caller has fewer rights than its callee. Because safe Rust cannot forge tokens, the type checker itself is claimed to execute this permission check at compile time.

Load-bearing premise

The load-bearing premise is that Cargo can be extended with a direct-dependency feature that is set only for direct dependencies and can never be enabled by a transitive dependency; the paper states this feature does not exist today and assumes it could be implemented because Cargo builds the dependency tree.

Editorial extensions

If this is right

In the intended configuration, a library whose Cargo.toml does not declare ReadPerm cannot perform a file read, because every read path in the wrapped standard library demands a ReadPerm token that no app_ wrapper will mint for it.
Enforcement is zero-cost at runtime: tokens vanish at compile time, so the only costs are compile time and the annotation burden on library developers.
Common supply-chain attacks that hide resource access inside popular libraries, such as a logging library reaching out to a remote server, would be stopped unless the package's declared permissions include that access.
The system does not claim to stop malicious code using unsafe Rust, which can transmute or construct arbitrary tokens; its stated target is accidental or hidden I/O in otherwise safe libraries.
Feature unification is an acknowledged weak point: if a package is both a direct and transitive dependency, the direct-dependency flag can become active for it, letting a transitive caller use its app_ functions and potentially escalate privileges.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

A practical test of the design would be to build the trust anchor as a sealed, audited crate for std's I/O surface and measure how many existing crates.io packages compile unchanged under PermRust annotations; the paper does not report such a measurement.
The same token mechanism could be extended to other ambient authorities beyond system I/O, such as environment variables, process spawning, or DNS lookups, since the token type does not care what the resource is.
An object-capability variant would yield finer-grained path- or IP-scoped permissions than the token model, at the cost of requiring all resources to be obtained at program start; the paper notes this trade-off but does not evaluate it.
If the direct-dependency feature cannot be added to Cargo, a compiler or package-manager plugin that rewrites the dependency graph could enforce the invariant, giving a concrete fallback for the paper's main open assumption.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Two things you should know. First, this is an unusually honest short concept paper: it lays out a capability-as-keys design for per-library I/O permissions in Rust, and Sect. 5 explicitly names its own limitations, including the feature-unification problem. Second, the central security claim in Sect. 4.1 — "no function can perform any I/O operation in safe Rust without having the correct access tokens" — is not delivered. The app_ macro in Listing 1.6 forges a ReadPerm token via unsafe transmute, making every app_ wrapper a safe entry point that performs I/O without the caller holding any token. The only restriction on who can call that entry point is a proposed Cargo "direct-dependency" feature that does not exist today, and the paper concedes that feature unification will activate it for packages that are simultaneously direct and indirect dependencies. That is the exact privilege escalation the system claims to prevent.

The theoretical core is in decent shape. The access-matrix adaptation is clean, the O(|E|·|O|) permission-check algorithm is correct, and the capability-as-keys framing maps naturally onto Rust's type system. The reference list covers OS-level sandboxes and capability languages and doesn't miss anything obvious. The authors also point to a proof-of-concept repository, which is good practice — though the code snippets in the paper itself already reveal the forge.

The soft spots are proportionate to the paper's size but fatal to the headline guarantee. The unsafe transmute is not a minor implementation detail; it is the point where a token is minted, violating the unforgeability criterion stated in Sect. 3.2. The Cargo direct-dependency feature is load-bearing and unprototyped. The attacker-model discussion dismisses the real-world impact as "unclear" and "unlikely," but for a security guarantee that is not an answer. A malicious or compromised library would have no qualms about calling an app_ function if the union of features grants it access, and the paper itself says that can happen.

This is a paper for a niche audience: researchers thinking about language-level capability systems or Rust supply-chain defenses. Those readers will find the model worth discussing, but the current version does not substantiate the core guarantee. I would send it to peer review as a concept paper with a request for major revision — the authors need to prototype the Cargo extension and either prove the feature-unification case or reposition PermRust as a best-effort annotation tool rather than a security guarantee. As it stands, it is an interesting sketch, not a working permission system.

Referee Report

3 major / 4 minor

Summary. PermRust proposes a token-based permission system for Rust that aims to restrict I/O operations per library at compile time. The paper formalizes the problem using the access matrix model, defines an abstract function tree, gives an O(|E|·|O|) algorithm to check whether a program is permission-respecting and privilege-escalation-free, and sketches a Rust proof-of-concept built from token types, proxy wrappers around standard-library I/O, and app_ entry points generated by a permissions macro. The authors claim that no function can perform any I/O operation in safe Rust without the correct access tokens, and position the system as a zero-cost mitigation against supply-chain attacks.

Significance. The formal access-control section is clean, and the algorithm in Theorem 1 is correct and clearly presented; the paper also makes its implementation available in a repository. The idea of encoding permissions as Rust types is attractive, and per-library granularity is potentially valuable for supply-chain scenarios. However, the central security guarantee is not demonstrated as stated. The app_ wrapper in Listing 1.6 fabricates tokens with an unsafe transmute, the enforcement depends on a Cargo 'direct-dependency' feature that does not exist, and the proxy standard-library example does not actually prevent calls to the original File::read. These are load-bearing gaps, not cosmetic issues. The paper reads best as a design sketch or position paper; the stated guarantee needs to be either substantially weakened or supported by a concrete design for the missing Cargo feature and a trusted token-minting path.

major comments (3)

[Section 4.1, Listing 1.6] The paper's central claim — 'no function can perform any I/O operation in safe Rust without having the correct access tokens' — is contradicted by the app_read_something wrapper shown in Listing 1.6. This is a safe callable function that performs I/O and does not require the caller to provide a token; instead, it creates a localPerm and uses unsafe { std::mem::transmute(self) } to obtain a &token::ReadPerm. The unsafe transmute is a token-forging step, and because app_read_something is safe, any caller can invoke it and obtain I/O capabilities without ever possessing a real token. The claim must be restated to exclude the trusted app_ layer, or the token minting must be moved to a trusted root that cannot be called by untrusted code.
[Sections 4.3 and 5 (Feature Unification)] The security of the permission-aware import layer rests entirely on a proposed Cargo feature, 'direct-dependency', that the paper admits does not exist. Under current Cargo semantics, feature unification will enable the feature for a package that is both a direct and a transitive dependency, and the paper itself concedes in Section 5 that this lets LibB call LibA's app_ functions and thereby escalate from no ReadPerm permission to full ReadPerm I/O. The authors call the real-world effect 'unclear' and 'unlikely', but for a security guarantee this is decisive: the guarantee is not delivered by current Cargo and depends on an unprototyped extension. The paper needs either a concrete design for the direct-dependency feature that resists feature unification, or a revised threat model that does not claim the guarantee.
[Section 4.1, Listing 1.4] The proxy FileProxy is described as 'puts itself in front of the original standard library', but the original std::fs::File::read method remains available in the actual Rust standard library. A function that obtains a std::fs::File can still call read directly without any token, so the statement 'the standard library now expects the correct token' is only true in an idealized modified standard library, not in the proof-of-concept. This deployment assumption must be made explicit, and the paper should explain how the replacement of the standard library is enforced (e.g., through a toolchain change or a restricted prelude); without that, the central claim fails even before considering the app_ wrapper.

minor comments (4)

[Sections 1 and 3] There are several typographical errors, including 'moderns software', 'a subjects has', 'theOSorthecompiler', and 'Consequentially'; these should be corrected.
[References] Reference [15] is incomplete: it gives only a URL fragment and no document title or publication venue; reference [14] also lacks a year and venue.
[Section 4.3] The paper would benefit from showing the permissions macro implementation rather than only referencing the repository, since the macro is central to generating app_ functions; a short code listing or a commit hash would improve reproducibility.
[Section 3.2] The terms 'capability-as-keys' and 'capabilities-as-keys' are used inconsistently; please standardize the terminology.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity found; PermRust implements imported capability concepts rather than deriving its central claim from itself.

full rationale

The paper's derivation chain is self-contained in the relevant sense. Section 3 imports the access-matrix and capability definitions from Lampson and Miller as inputs, defines permission-respecting and privilege-escalation-free trees relative to those inputs, and gives an algorithm that checks exactly those definitions; this is a direct decision procedure, not a circular derivation. Section 4 then implements the capability-as-keys model in Rust tokens, with the standard library modified to require tokens. No target result is defined in terms of itself, no fitted parameter is relabeled as a prediction, and no load-bearing premise is justified by a self-citation chain; the only author self-reference is the accompanying Git repository [7], which is supporting material rather than the argument. The paper's central safety claim is a design assertion, and the concerns raised by a skeptical reader, such as the unsafe transmute in Listing 1.6 or the nonexistent Cargo direct-dependency feature, are correctness or attacker-model limitations that the paper itself partially acknowledges in Section 5; they do not make the derivation circular. Accordingly, the appropriate circularity score is 0.

Assumptions & free parameters 0 free parameters · 4 assumptions · 1 invented entities

The central claim rests on a handful of unproved modeling and implementation assumptions, enumerated above. No free parameters or fitted constants appear anywhere in the paper.

assumptions (4)

domain assumption The Access Matrix Model can be adapted to per-function permissions with subjects as functions and objects as I/O interfaces.
Sect. 3.1 defines permission matrix over a program; this mapping is the paper's modeling choice, not a theorem.
domain assumption Rust's visibility and borrow checker make token types unforgeable in safe Rust.
Sect. 3.2 argues safe Rust meets capability language requirements; this is asserted, not formally verified.
ad hoc to paper Cargo can implement a direct-dependency feature that cannot be activated transitively.
Sect. 4.3 states this feature is not currently implemented but assumes it could be added.
domain assumption The standard library can be rewritten to require tokens and remains the trust anchor.
Sect. 4.1 and the Costs paragraph in Sect. 5 depend on modifying std without breaking safety; no implementation of the modified standard library is shown.

invented entities (1)

Token types such as ReadPerm
purpose: Capability-as-keys to grant call permission to I/O functions.
Introduced in Listing 1.1; no independent verification of unforgeability is provided beyond reliance on Rust visibility.

how reviews work

0 comments

Cite this review

Pith. "Pith review of PermRust: A Token-based Permission System for Rust." pith.science (2026). https://pith.science/paper/ZLRESPFF

@misc{pith2026250611701,
  author       = {Pith},
  title        = {Pith review of: PermRust: A Token-based Permission System for Rust},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ZLRESPFF}},
  note         = {Machine review of arXiv:2506.11701}
}

read the original abstract

Permission systems which restrict access to system resources are a well-established technology in operating systems, especially for smartphones. However, as such systems are implemented in the operating system they can at most manage access on the process-level. Since moderns software often (re)uses code from third-parties libraries, a permission system for libraries can be desirable to enhance security. In this short-paper, we adapt concepts from capability systems building a novel theoretical foundation for permission system at the level of the programming language. This leads to PermRust, a token-based permission system for the Rust programming language as a zero cost abstraction on top of its type-system. With it access to system resources can be managed per library.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

21 extracted references · 21 canonical work pages

[1]

org/history/joule/

Agorics, I.: Joule: Distributed application foundations (1995), http://erights. org/history/joule/

work page 1995
[2]

FreeBSD Journal (2017)

Anderson, J.: Sandboxing techniques. FreeBSD Journal (2017)

work page 2017
[3]

Better Call Saltzer \& Schroeder: A Retrospective Security Analysis of SolarWinds \& Log4j

Chowdhury, P.D., Tahaei, M., Rashid, A.: Better call saltzer & schroeder: A ret- rospective security analysis of solarwinds & log4j. arXiv:2211.02341 (2022)

work page Pith review arXiv 2022
[4]

In: Proceedings 2021 NDSS Symposium

Duan, R., Alrawi, O., Kasturi, R.P., Elder, R., Saltaformaggio, B., Lee, W.: To- wards measuring supply chain attacks on package managers for interpreted lan- guages. In: Proceedings 2021 NDSS Symposium. Internet Society (2021)

work page 2021
[5]

de Gruyter (2023)

Eckert, C.: IT-Sicherheit: Konzepte–Verfahren–Protokolle. de Gruyter (2023)

work page 2023
[6]

In: 2019 IEEE/ACM 41st ICSE-NIER

Garrett, K., Ferreira, G., Jia, L., Sunshine, J., Kästner, C.: Detecting suspicious package updates. In: 2019 IEEE/ACM 41st ICSE-NIER. pp. 13–16. IEEE (2019)

work page 2019
[7]

Gehring, L.: Code for permrust: A token-based permission system for rust,https: //git.sr.ht/~lgehr/token_based_permission_system_code

work page
[8]

Gruenbacher, A., Arnold, S.: Apparmor technical documentation (2007)

work page 2007

Show all 21 references

[9]

SIGOPS Oper

Lampson, B.W.: Protection. SIGOPS Oper. Syst. Rev.8(1), 18–24 (jan 1974)

1974
[10]

Miller, M.S., Yee, K.P., Shapiro, J.: Capability myths demolished. Tech. rep., Johns Hopkins University Systems Research (2003)

2003
[11]

Pfretzschner, B., ben Othmane, L.: Identification of dependency-based attacks on node. js. In: Proceedings of the 12th International Conference on Availability, Re- liability and Security. pp. 1–6 (2017)

2017
[12]

Pony Developers: Pony,https://www.ponylang.io
[13]

In: NDSS (2016)

Seo, J., Kim, D., Cho, D., Shin, I., Kim, T.: Flexdroid: Enforcing in-app privilege separation in android. In: NDSS (2016)

2016
[14]

Steed, G., Drossopoulou, S.: A principled design of capabilities in pony
[15]

Stiegler, M.: http://www.skyhunter.com/marcs/ewalnut.html#SEC41
[16]

The Cargo Team: The cargo book,https://doc.rust-lang.org/cargo/
[17]

In: Computer Security - 21st ES- ORICS

Wang, F., Zhang, Y., Wang, K., Liu, P., Wang, W.: Stay in your cage! A sound sandbox for third-party libraries on android. In: Computer Security - 21st ES- ORICS. pp. 458–476. Springer (2016) 12 Lukas Gehring, Sebastian Rehms, and Florian Tschorsch

2016
[18]

In: Proceedings of the 4th ACM Conference on Data and Application Security and Privacy

Wang, Y., Hariharan, S., Zhao, C., Liu, J., Du, W.: Compac: Enforce component- level access control in android. In: Proceedings of the 4th ACM Conference on Data and Application Security and Privacy. pp. 25–36 (2014)

2014
[19]

Wikberg, M.: Secure computing: Selinux (2007), https:// citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi= 242132951b3157f1d887d507b1c0289fd27e16eb

2007
[20]

ACM Sigplan notices 8(2), 28–34 (1973)

Wulf, W., Shaw, M.: Global variable considered harmful. ACM Sigplan notices 8(2), 28–34 (1973)

1973
[21]

In:USENIX security symposium

Zimmermann, M., Staicu, C.A., Tenny, C., Pradel, M.: Small world with high risks: A studyof security threats in thenpm ecosystem. In:USENIX security symposium. vol. 17 (2019)

2019

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [1]

org/history/joule/

Agorics, I.: Joule: Distributed application foundations (1995), http://erights. org/history/joule/

work page 1995

[2] [2]

FreeBSD Journal (2017)

Anderson, J.: Sandboxing techniques. FreeBSD Journal (2017)

work page 2017

[3] [3]

Better Call Saltzer \& Schroeder: A Retrospective Security Analysis of SolarWinds \& Log4j

Chowdhury, P.D., Tahaei, M., Rashid, A.: Better call saltzer & schroeder: A ret- rospective security analysis of solarwinds & log4j. arXiv:2211.02341 (2022)

work page Pith review arXiv 2022

[4] [4]

In: Proceedings 2021 NDSS Symposium

Duan, R., Alrawi, O., Kasturi, R.P., Elder, R., Saltaformaggio, B., Lee, W.: To- wards measuring supply chain attacks on package managers for interpreted lan- guages. In: Proceedings 2021 NDSS Symposium. Internet Society (2021)

work page 2021

[5] [5]

de Gruyter (2023)

Eckert, C.: IT-Sicherheit: Konzepte–Verfahren–Protokolle. de Gruyter (2023)

work page 2023

[6] [6]

In: 2019 IEEE/ACM 41st ICSE-NIER

Garrett, K., Ferreira, G., Jia, L., Sunshine, J., Kästner, C.: Detecting suspicious package updates. In: 2019 IEEE/ACM 41st ICSE-NIER. pp. 13–16. IEEE (2019)

work page 2019

[7] [7]

Gehring, L.: Code for permrust: A token-based permission system for rust,https: //git.sr.ht/~lgehr/token_based_permission_system_code

work page

[8] [8]

Gruenbacher, A., Arnold, S.: Apparmor technical documentation (2007)

work page 2007