nono Sandboxing Environment

The nono project is organized into several crates with distinct responsibilities. Understanding these boundaries is critical for both development and integration:

• crates/nono (Core Library): The policy-free sandbox primitive. It handles the capability model, path canonicalization, Landlock/Seatbelt application, diagnostics, keystore helpers, host filtering, trust/attestation types, rollback object storage, and supervisor protocol types. It only applies capabilities explicitly supplied by the caller.
• crates/nono-cli (CLI & Runtime): The layer for user policy, embedded profiles, policy group resolution, protected path handling, execution strategy selection, environment preparation, proxy runtime wiring, credential loading, audit, rollback, trust commands, package/registry workflows, and ephemeral tool isolation.
• crates/nono-proxy (Network Proxy): A network proxy running outside the child sandbox. It provides controlled loopback access to the sandboxed child and implements CONNECT host filtering, reverse proxy credential injection, external proxy chaining, TLS interception (L7), endpoint filtering, OAuth2, and optional SPIFFE support.
• bindings/c (nono-ffi): The C ABI wrapper around the core library. Use this for FFI-based integrations, ensuring pointer validity, ownership, and allocation/free symmetry.

nono operates using three primary trust domains to ensure the sandboxed process remains untrusted and contained:

1. Kernel: The fully trusted layer that enforces Landlock rules, delivers seccomp notifications, and blocks unauthorized syscalls.
2. Supervisor (parent): The trusted layer that records audit events, receives trapped syscalls, consults approval backends, opens files, and injects file descriptors. It also manages the network proxy and PTY relay.
3. Sandboxed child: The untrusted layer where the agent command runs under full kernel enforcement.

When proxy mode is active, a fourth domain is added:

• Network proxy: A trusted component running within the supervisor that filters outbound connections by host, injects credentials, and enforces deny CIDRs. The sandboxed child is restricted to localhost:<port> via kernel-level blocking; all other outbound TCP is prevented.

The nono security model relies on a supervisor-child architecture. The supervisor (the parent process) is a non-privileged Rust binary that manages the sandbox. It is designed to be a privilege boundary in the downward direction (restricting the child) rather than an upward escalation vector.

Key security properties:

• Unprivileged Execution: The supervisor runs as the same user who invoked nono run. It does not require root, CAP_SYS_ADMIN, or setuid permissions.
• Memory Safety: The supervisor is written in Rust, which prevents common vulnerabilities like buffer overflows and use-after-free. IPC (Inter-Process Communication) uses length-prefixed JSON parsed via serde.
• Isolation: There is no shared memory, no signal-based control channel, and the child is prevented from using ptrace on the supervisor.
• Minimal Attack Surface: The supervisor's IPC socket is an anonymous socketpair(), and its network exposure is limited to a random localhost port protected by a session token when in proxy mode.

nono employs a defense-in-depth strategy using two distinct kernel mechanisms:

Layer 1: Landlock (The Floor)

Landlock provides a permanent, irreversible security floor. Once restrict_self() is called, the child process is restricted to its initial capability set. This layer is unprivileged and inherited by all child processes/threads. It ensures that even if the supervisor fails, the child cannot access paths outside its allowed set.

Layer 2: seccomp-notify (The Gate)

This layer provides dynamic capability expansion. A BPF filter traps openat and openat2 syscalls and routes them to the supervisor.

• Deny: The supervisor returns EPERM (the syscall never reaches Landlock).
• Approve: The supervisor opens the file itself and injects the file descriptor into the child via SECCOMP_IOCTL_NOTIF_ADDFD.

Critical Ordering: seccomp runs before Landlock. This allows the supervisor to grant temporary access to files that Landlock would otherwise block, while Landlock acts as a fallback to catch any supervisor errors or escapes.

nono uses a capability-based security model with kernel-level enforcement based on a deny by default, allow explicitly principle. When running a command through nono, only explicitly granted access is permitted; all other access is blocked at the kernel level.

Security Guarantees

• Path Traversal Protection: Prevents escaping allowed directories using ../ sequences.
• Symlink Escape Protection: Paths are canonicalized at grant time to prevent symlinks from pointing outside the sandbox.
• Credential Theft Protection: Sensitive paths (like SSH, AWS, or Kubernetes configs) are blocked by default even if a parent directory is allowed.
• Child Process Isolation: All child processes inherit the sandbox restrictions.
• Privilege Escalation Prevention: The sandbox is applied before exec(), ensuring no window of elevated privilege exists.

Security Limitations

• Kernel Exploits: Does not protect against vulnerabilities in the host kernel.
• Covert Channels: Does not prevent information leakage via timing or CPU usage patterns.
• Resource Exhaustion: Does not limit CPU, memory, or disk usage (no DoS protection).
• Data within Allowed Paths: If a directory is granted, all files within it are accessible.
• TOCTOU Races: A minimal window exists between path canonicalization and sandbox application.

nono provides security by using kernel-enforced sandboxing (via Landlock or Seatbelt) rather than application-level permission checks. This ensures that even if an agent is compromised, performs a prompt injection, or loads a malicious dependency, it cannot bypass the security boundaries because the enforcement happens in kernel space, not within the agent's own process.

Key security properties include:

• Irreversibility: Once the sandbox is initialized (e.g., via landlock_restrict_self()), there is no API to undo the restrictions.
• Enforcement Authority: The kernel intercepts system calls before they succeed, preventing unauthorized access.
• Process Inheritance: All child processes spawned by a sandboxed agent automatically inherit the same restrictions.
• Reduced Attack Surface: By relying on battle-tested kernel implementations, nono avoids common application-level bugs like symlink bypasses or TOCTOU (Time-of-Check to Time-of-Use) race conditions.

The nono profile JSON schema is undergoing a restructure to improve clarity and safety. The new schema moves away from a top-level policy key and introduces more granular control over groups, commands, and filesystem access.

Key Changes:

• Groups: Uses groups.include and groups.exclude instead of legacy policy structures.
• Commands: Uses commands.allow and commands.deny.
• Filesystem: Expanded to include deny and bypass_protection (formerly override_deny).
• Security: Narrowed scope to remove redundant top-level keys.

Implementation Note: The system uses a two-layer parsing approach. Canonical structs use #[serde(deny_unknown_fields)] to ensure strictness, while transient legacy-capture types (like LegacyPolicyPatch and RawSecurityConfig) handle backward compatibility by draining old keys into the new canonical format during deserialization.

nono is a capability-based sandbox that provides fine-grained, kernel-enforced isolation at the OS syscall level. It is designed for agents acting within an operating context, providing precise control over paths, domains, sockets, environment variables, and operations.

Key Distinctions:

• What it is: A tool for per-path and per-operation capability control using Landlock (Linux) or Seatbelt (macOS).
• What it is not: It is not a hypervisor (like Firecracker) or a container runtime. It does not provide a separate kernel boundary or hardware-level memory isolation; the sandboxed process shares the host kernel.
• Policy Dependency: The effectiveness of nono depends on the accuracy of the applied policy. Because filesystem layouts vary across Linux distributions, policies must be tuned to the specific environment to avoid gaps.

Deployment Posture Recommendation: For highest-assurance deployments, use a layered approach:

1. Outer Perimeter: Use a lightweight VM (e.g., Firecracker) or hardened container runtime (e.g., Edera, Kata) for hardware-level isolation and namespace separation.
2. Inner Granularity: Run nono inside that boundary to provide fine-grained capability control (e.g., restricting access to specific files within a mounted directory).