Course contentsShow
← Rust
Lesson 183 of 1,9102. The Ownership ModelFree lesson

Ownership-Based Security Policies

Enforce data access controls by requiring ownership of capability tokens.

In this lesson, you will learn how to use Rust’s ownership system as a gatekeeper to enforce strict security policies within your applications.

The Concept: Capability Tokens

In complex systems, we often need to ensure that only authorized code can perform sensitive operations, like accessing a database or writing to a log file. Instead of relying on global boolean flags or fragile runtime checks, we can use the Ownership Model to create "Capability Tokens."

A capability token is a struct that represents the right to perform a specific action. Because of Rust's ownership rules, we can ensure that once a token is used or transferred, it cannot be duplicated or bypassed. If a function requires ownership of a FileSystemAccess token, the compiler forces the caller to prove they have the right to provide that token.

Implementing a Security Policy

Consider a scenario where only one module is allowed to update a sensitive system clock. We define a token type that cannot be cloned:

pub struct ClockAuthToken(()); // Empty struct as a capability

pub struct SystemClock {
    time: u64,
}

impl SystemClock {
    // Only the holder of ClockAuthToken can update the time
    pub fn update_time(&mut self, _token: ClockAuthToken, new_time: u64) {
        self.time = new_time;
    }
}

By making the ClockAuthToken constructor private to a specific module, you ensure that no other part of the program can manufacture the token needed to call update_time.

When you pass this token into a function, you consume the capability. If you want to keep the capability for future use, you must return it back to the caller. This creates a rigorous, compile-time audit trail of who is allowed to perform security-sensitive operations. Because the compiler tracks the movement of these tokens through your code, it becomes mathematically impossible for an unauthorized segment of your program to execute a protected operation—it simply wouldn't be able to provide the required ClockAuthToken to the function signature.

Key Takeaway: By requiring ownership of a non-cloneable capability token as a function argument, you enforce security policies at compile-time, ensuring only authorized code paths can perform sensitive operations.