Sui Randomness: Fixing False Positives In Framework

# Sui Randomness: Fixing False Positives in Framework

When developing smart contracts on the **Sui blockchain**, you'll inevitably want to incorporate **randomness** into your dApps. This is crucial for a variety of applications, from **gaming and NFTs to fair distribution mechanisms**. The Sui framework provides built-in tools to achieve this, and a lint called `public_random_access_v2` is in place to help developers avoid common pitfalls, like exposing sensitive random objects that could be exploited through **front-running attacks**. However, as with any automated tool, sometimes the lint can be a bit *too* enthusiastic, flagging legitimate framework functions as potential issues. This article delves into a specific instance where the `public_random_access_v2` lint incorrectly flags the canonical Sui framework function `random::new_generator` as a problem, and explores how we can implement a **framework allowlist** to distinguish genuine security risks from intended framework usage.

## Understanding the `public_random_access_v2` Lint and the False Positive

The **`public_random_access_v2` lint** is designed with a noble purpose: to safeguard your dApps by preventing the accidental exposure of `Random` objects. In the world of blockchain, certain data, especially random numbers, should not be publicly accessible before a transaction is finalized. This is because malicious actors, often referred to as validators in this context, could observe these random values before including a transaction. If they can see the outcome of a random event, they might manipulate their own transactions or prioritize specific transactions to their advantage, leading to unfair outcomes or exploitation. This is known as a **front-running attack**. The lint aims to catch user-written code that makes `Random` objects publicly accessible, nudging developers to use `entry` visibility instead for such sensitive operations. This ensures that the random number generation process is properly managed and secured within the transaction lifecycle.

However, the lint's current implementation fires an alert on a very specific function within the Sui framework itself: `sui::random::new_generator`. The evidence provided by the lint in `random.move:143` states: "Public function `new_generator` exposes `sui::random::Random` object. This enables front-running attacks where validators can see random values before including transactions. Use `entry` visibility instead." This is where the **false positive** arises. The `sui::random::new_generator` function is not an arbitrary piece of code written by a user that inadvertently exposes randomness; it is, in fact, the *intended and documented* way to generate usable random numbers within the Sui ecosystem. The lint, by flagging this essential framework function, creates unnecessary noise and confusion for developers working with the Sui framework, obscuring genuine security concerns with phantom ones. This highlights a common challenge in static analysis: distinguishing between malicious intent and designed functionality, especially within a complex framework.

## The Canonical Way: Using `sui::random::new_generator`

To truly appreciate why the `public_random_access_v2` lint's flagging of `sui::random::new_generator` is a false positive, we need to understand its role within the Sui framework. The Sui documentation explicitly guides developers on how to harness the power of randomness. As stated in the official **Sui Randomness Docs** (found at [https://docs.sui.io/concepts/sui-move-concepts/randomness](https://docs.sui.io/concepts/sui-move-concepts/randomness)), the recommended approach is clear: "Call `random::new_generator` to create a RandomGenerator from the shared Random object." This function is not a security vulnerability; it is the **gateway to secure and predictable random number generation** on the Sui network. Let's look at the framework's own definition:

```move
/// Create a new RandomGenerator from the Random object.
public fun new_generator(r: &Random, ctx: &mut TxContext): RandomGenerator {
    // ... implementation details ...
}

This function takes a reference to a Random object and a transaction context (TxContext) to produce a RandomGenerator. This RandomGenerator is then used to produce actual random bytes or values within your smart contract logic. The framework is designed such that this process, when used as intended through new_generator, is secure and does not lead to exploitable front-running scenarios. The lint, however, is not differentiating between user code that might misuse the Random object and the framework's own curated method for its controlled access. This is why a mechanism to allowlist known, safe framework functions is essential for improving the accuracy and utility of such linters.

The Solution: Implementing a Framework Allowlist

To resolve the issue of the public_random_access_v2 lint generating false positives on essential Sui framework functions, the most effective approach is to implement a framework allowlist. This allowlist would serve as a curated list of module and function pairs that are known to be safe and are part of the intended framework usage, even if they involve operations that would normally trigger the lint. By pre-approving these specific functions, the linter can intelligently skip them, focusing its attention on actual user-defined code where vulnerabilities are more likely to occur.

A practical way to implement this is by defining a constant array of tuples, where each tuple contains the module name and the function name that should be exempted. For instance, in Rust, this could look like:

const RANDOM_ACCESS_ALLOWLIST: &[(&str, &str)] = &[
    ("sui::random", "new_generator"),
    ("sui::random", "generate_bytes"),
    // ... other known safe framework functions can be added here ...
];

fn should_skip_random_access_warning(module: &str, function: &str) -> bool {
    RANDOM_ACCESS_ALLOWLIST.iter()
        .any(|(m, f)| module.ends_with(m) && function == *f)
}

This RANDOM_ACCESS_ALLOWLIST would contain entries like ("sui::random", "new_generator"), explicitly telling the linter that this specific function within the sui::random module is safe to use and should not trigger a warning. The should_skip_random_access_warning function would then check if the current module and function being linted are present in this allowlist. If a match is found, the warning is suppressed. This approach ensures that the lint's core purpose of catching genuine security flaws in user code remains intact, while simultaneously eliminating the noise caused by legitimate framework operations. This targeted approach is far more precise than broader exclusion rules, providing a robust and maintainable solution.

An Alternative: Module-Level Allowlist for Framework Code

While a function-specific allowlist is highly precise, there might be scenarios where a broader, module-level allowlist offers a more convenient and scalable solution, especially when dealing with core framework components. This approach recognizes that entire modules within the Sui framework are developed with security and intended functionality in mind. Instead of meticulously listing every single safe function, we can simply identify and trust entire namespaces that belong to the framework. This can be particularly useful as the framework evolves and new safe functions are introduced.

Consider a scenario where you want to exempt all functions originating from official Sui modules. A function like is_framework_module could be implemented to check if a given module name starts with prefixes commonly associated with the Sui framework. This would look something like:

fn is_framework_module(module: &str) -> bool {
    module.starts_with("sui::") || 
    module.starts_with("std::") || // Standard library modules are also generally trusted
    module.starts_with("sui_system::") // System-level contracts
}

When the public_random_access_v2 lint is evaluating a piece of code, it could first call is_framework_module on the originating module. If the function returns true, the lint would immediately skip that module, assuming all its functions are safe and intended. This strategy is less granular than the function-specific allowlist but can be very effective for reducing noise from trusted framework code. It's important to note that this approach requires careful consideration of what constitutes a