# Microsandbox Security Implications: Defense-in-Depth Through Micro-VM Isolation

> Explore microsandbox security implications. Learn how micro VM isolation provides defense-in-depth, blocking privilege escalation for enhanced workload protection.

- Repository: [Super Rad Company/microsandbox](https://github.com/superradcompany/microsandbox)
- Tags: deep-dive
- Published: 2026-08-20

---

**Microsandbox runs each workload inside a lightweight micro-VM isolated by the kernel and hypervisor, with configurable security profiles that range from default container-like privileges to restricted hardening that blocks privilege escalation.**

Understanding the security implications of any sandbox technology requires examining its isolation boundaries, capability controls, and runtime enforcement mechanisms. Microsandbox provides a **defense-in-depth architecture** that combines hardware-level virtualization with fine-grained Linux capability management. This analysis examines how the `superradcompany/microsandbox` repository implements security through its dual-profile system and where these controls are enforced in the codebase.

## Security Architecture Overview

Microsandbox's security model operates at two distinct layers:

1. **Micro-VM isolation** — Each workload runs in its own lightweight virtual machine, providing CPU and memory isolation from the host and other sandboxes
2. **Capability-based hardening** — The **security profile** system (`SecurityProfile::Default` vs `SecurityProfile::Restricted`) controls what privileges the guest kernel exposes to running processes

The security profile is defined in [`sdk/rust/lib/sandbox/config.rs#L1432`](https://github.com/superradcompany/microsandbox/blob/main/sdk/rust/lib/sandbox/config.rs#L1432), where `SecurityProfile::Default` serves as the baseline behavior. This design allows operators to tune security posture per workload without reconfiguring the underlying virtualization infrastructure.

## Security Profiles Explained

### Default Profile: Container-Compatible Privileges

The **default profile** maintains Linux privileges comparable to standard container runtimes. The guest retains capabilities including:

- `CAP_SYS_ADMIN` — allows privileged system administration operations
- Full mount capabilities — supports `tmpfs`, bind mounts, and filesystem manipulation
- Unrestricted privilege escalation paths

This profile enables use cases like **Docker-in-Docker**, `sudo` operations, and complex build pipelines that require elevated permissions. However, the analysis of [`sdk/rust/lib/runtime/spawn.rs#L2514`](https://github.com/superradcompany/microsandbox/blob/main/sdk/rust/lib/runtime/spawn.rs#L2514) reveals that these same capabilities create attack surface: a compromised process could manipulate kernel namespaces or escalate to host-level access.

### Restricted Profile: Hardened Execution Environment

The **restricted profile** implements three hardening measures as verified by the integration test suite in [[`sdk/rust/tests/security_profile.rs`](https://github.com/superradcompany/microsandbox/blob/main/sdk/rust/tests/security_profile.rs)](https://github.com/superradcompany/microsandbox/blob/main/sdk/rust/tests/security_profile.rs):

| Hardening Measure | Security Effect | Verification Assertion |
|-------------------|---------------|----------------------|
| `no_new_privs` flag | Prevents privilege escalation via setuid binaries | `assert_no_new_privs(&restricted, "1")` |
| `CAP_SYS_ADMIN` dropped | Blocks privileged syscalls and namespace manipulation | `assert_cap_sys_admin(&restricted, false)` |
| `nosuid,nodev` mount flags | Prevents execution of setuid programs and device node creation | `assert_mount_has_flags(..., &["nosuid", "nodev"])` |

These restrictions are applied at VM spawn time, creating an **immutable security boundary** that persists for the sandbox lifecycle.

## Profile Configuration and Parsing

Microsandbox ensures consistent security policy across all entry points through unified profile parsing:

**CLI parsing** — [`crates/cli/lib/commands/common.rs#L2644`](https://github.com/superradcompany/microsandbox/blob/main/crates/cli/lib/commands/common.rs#L2644) handles the `--security-profile` flag:

```bash

# Default (privileged container-like behavior)

msb sandbox create my-workload --image alpine --cpus 1 --memory 256

# Restricted (hardened, no privilege escalation)

msb sandbox create my-workload --image alpine --cpus 1 --memory 256 \
    --security-profile restricted

```

**Daemon configuration** — [`crates/agentd/lib/config.rs#L575`](https://github.com/superradcompany/microsandbox/blob/main/crates/agentd/lib/config.rs#L575) parses the same profile strings and also checks `MSB_SECURITY_PROFILE` environment variable:

```rust
// Environment variable override for policy enforcement
read_env(ENV_SECURITY_PROFILE)  // maps to MSB_SECURITY_PROFILE

```

This dual-path parsing ensures that security policies defined in environment variables, configuration files, or command-line arguments are validated identically before reaching the runtime.

## Threat Model and Security Implications

### Privilege Escalation Risks

In the **default profile**, a compromised workload retains `CAP_SYS_ADMIN` capability. As implemented in the Linux kernel, this capability allows:

- Mount namespace manipulation
- Access to kernel debugging interfaces
- Potential container escape through namespace vulnerabilities

The **restricted profile** eliminates this path by stripping `CAP_SYS_ADMIN` and enabling `no_new_privs`, making privilege escalation **structurally impossible** regardless of kernel bugs in setuid handling.

### Filesystem Attack Surface

The mount flag restrictions (`nosuid`, `nodev`) in restricted mode prevent two common attack vectors:

- **Setuid binary exploitation** — Even if an attacker deposits a malicious setuid binary, the `nosuid` flag prevents privilege elevation
- **Device node attacks** — `nodev` prevents creation of device special files that could access host hardware directly

### Cross-Sandbox Isolation

While security profiles control **intra-sandbox** capabilities, the **micro-VM architecture** provides **inter-sandbox** isolation. Each sandbox receives dedicated virtual CPU and memory resources, reducing side-channel leakage risks that affect container-based isolation. The restricted profile does not alter this baseline but adds **capability-level** hardening within each VM.

### Network Attack Considerations

Security profiles do not directly constrain network access. Network segmentation requires separate firewall configuration via Microsandbox's networking module. For defense-in-depth, restricted-profile sandboxes should be combined with network policies that limit egress to required endpoints only.

## Code Examples: Implementing Secure Sandboxes

### Rust SDK: Creating a Restricted Sandbox

```rust
use microsandbox::{Sandbox, sandbox::SecurityProfile};

let hardened_sb = Sandbox::builder("production-workload")
    .image("registry.example.com/app:v1.2.3")
    .cpus(2)
    .memory(512)
    .replace()
    .security(SecurityProfile::Restricted)  // Enable hardening
    .create()
    .await
    .expect("sandbox creation failed");

// Runtime guarantees:
// - no_new_privs: prevents privilege escalation
// - CAP_SYS_ADMIN: dropped, privileged syscalls return EPERM
// - Mounts: nosuid,nodev flags applied automatically

```

### Programmatic Profile Selection

```rust
use microsandbox::sandbox::SecurityProfile;

// Select profile based on deployment context
let profile = if std::env::var("PRODUCTION").is_ok() {
    SecurityProfile::Restricted
} else {
    SecurityProfile::Default  // Development flexibility
};

let sb = Sandbox::builder("dynamic-workload")
    .image("alpine:latest")
    .security(profile)
    .create()
    .await?;

```

### Verifying Security Posture

The test patterns from [[`sdk/rust/tests/security_profile.rs`](https://github.com/superradcompany/microsandbox/blob/main/sdk/rust/tests/security_profile.rs)](https://github.com/superradcompany/microsandbox/blob/main/sdk/rust/tests/security_profile.rs) demonstrate runtime verification:

```rust
// These assertions mirror the integration test suite
assert_no_new_privs(&sandbox, "1");           // /proc/self/status check
assert_cap_sys_admin(&sandbox, false);        // CapEff bitmask verification
assert_mount_has_flags(&mount_point, &["nosuid", "nodev"]);

```

## Key Source Files Reference

| Component | File Path | Security Relevance |
|-----------|-----------|-------------------|
| Profile definition | [`sdk/rust/lib/sandbox/config.rs`](https://github.com/superradcompany/microsandbox/blob/main/sdk/rust/lib/sandbox/config.rs) | `SecurityProfile` enum, default values |
| Runtime enforcement | [`sdk/rust/lib/runtime/spawn.rs`](https://github.com/superradcompany/microsandbox/blob/main/sdk/rust/lib/runtime/spawn.rs) | Profile application at VM creation |
| CLI argument parsing | [`crates/cli/lib/commands/common.rs`](https://github.com/superradcompany/microsandbox/blob/main/crates/cli/lib/commands/common.rs) | `--security-profile` flag handling |
| Daemon configuration | [`crates/agentd/lib/config.rs`](https://github.com/superradcompany/microsandbox/blob/main/crates/agentd/lib/config.rs) | Environment variable parsing |
| Integration tests | [`sdk/rust/tests/security_profile.rs`](https://github.com/superradcompany/microsandbox/blob/main/sdk/rust/tests/security_profile.rs) | Behavioral verification suite |
| Public API types | [`packages/microsandbox-types/rust/lib/domain.rs`](https://github.com/superradcompany/microsandbox/blob/main/packages/microsandbox-types/rust/lib/domain.rs) | `SecurityProfile` export |

## Summary

- **Microsandbox provides micro-VM isolation** as the foundation, with security profiles adding capability-level hardening
- **Default profile** offers container-compatible flexibility but retains privilege escalation risks through `CAP_SYS_ADMIN`
- **Restricted profile** enforces `no_new_privs`, drops `CAP_SYS_ADMIN`, and applies `nosuid,nodev` mount flags
- **Profile parsing is unified** across CLI (`--security-profile`), daemon configuration, and `MSB_SECURITY_PROFILE` environment variable
- **Production deployments** should use `SecurityProfile::Restricted` to minimize attack surface, with network policies applied separately

## Frequently Asked Questions

### What happens if I don't specify a security profile?

Microsandbox uses `SecurityProfile::Default` automatically. The guest retains full Linux capabilities including `CAP_SYS_ADMIN`, equivalent to a privileged container. For production workloads handling untrusted code, explicitly set `--security-profile restricted` to prevent privilege escalation.

### Can a restricted sandbox still run Docker or build containers?

No. The restricted profile strips `CAP_SYS_ADMIN`, which is required for Docker-in-Docker operations and privileged container builds. Use the default profile for CI/CD pipelines requiring nested virtualization, accepting the elevated security risk and isolating those sandboxes appropriately.

### How do I enforce restricted profiles across my organization?

Set the `MSB_SECURITY_PROFILE` environment variable to `restricted` on all Microsandbox hosts. The agent daemon parses this variable in [`crates/agentd/lib/config.rs`](https://github.com/superradcompany/microsandbox/blob/main/crates/agentd/lib/config.rs) and applies it unless explicitly overridden. Combine with policy-as-code tools to prevent `--security-profile default` usage in production namespaces.

### Does the restricted profile protect against kernel exploits?

The restricted profile reduces exploit surface by disabling privilege escalation paths, but cannot prevent exploitation of kernel vulnerabilities directly. The micro-VM isolation provides stronger protection: each sandbox runs its own kernel instance, so host kernel compromise requires breaking the hypervisor boundary rather than a container escape.