Appearance

Secure Sandbox Storage ​

Guidance for securing the on‑device Secure Sandbox storage across Windows, macOS, and Linux. This includes encryption, access control, validation posture, and how to place storage on different local volumes (for example, non‑system disks or removable devices) in a secure way.

What You'll Learn

  • Security model for the Secure Sandbox Files storage
  • Filesystem and encryption requirements by platform
  • Preventing insecure paths (UNC/NFS/SMB, unsupported filesystems like FAT/exFAT)
  • Securely using non‑system volumes and stable volume identifiers
  • Removable media policy (allowlists, encryption requirements)
  • Example configurations and validation posture checks

Storage model overview ​

Secure Sandbox storage is a local, posture‑validated storage area that lives on the user’s device. The Launcher treats it as a Secure Sandbox storage volume, regardless of the underlying operating system.

These two serve different purposes and are configured in different places. Do not mix them. For a side-by-side comparison of Files tab Storage Contexts vs structured mounts, see Storage Contexts vs Structured Mounts.

Cloud storage integration (Turbo Drive) ​

To provide direct, secure access to cloud storage providers and file shares without relying on local sync clients or UNC/NFS/SMB paths, use Turbo Drive. Turbo Drive mounts provider-backed namespaces (for example, OneDrive, Dropbox, SMB) under a virtual drive or mount point on the endpoint (such as T: on Windows, a File Provider domain at ~/Library/CloudStorage/Turbo Drive on macOS, or /mnt/tdrive on Linux).

Expose only the required folders to applications by mapping Turbo Drive paths into the container via policy-authored structured mounts.

Key guidance

  • Keep Files tab Storage Contexts on local Secure Sandbox storage volumes that meet the platform’s posture requirements.
  • For cloud storage access, map from Turbo Drive to stable container destinations using structured mounts. Common patterns:
    • Windows: T\\OneDrive, T\\Dropbox, T\\SMB
    • macOS: ~/Library/CloudStorage/Turbo Drive/OneDrive, ~/Library/CloudStorage/Turbo Drive/Dropbox, ~/Library/CloudStorage/Turbo Drive/SMB (in policy source values, write the home directory as @HOME@)
    • Linux: /mnt/tdrive/OneDrive, /mnt/tdrive/Dropbox, /mnt/tdrive/SMB
  • Apply ABAC gating and choose read-only or read-write as appropriate per app/profile.

Learn more:

Security requirements and best practices ​

1) Filesystem and path requirements ​

Secure Sandbox Storage Contexts are always local to the device. Network filesystems are not supported as Storage Context roots.

General rules

  • Each Storage Context source resolves to a local filesystem path on the endpoint.
  • UNC/NFS/SMB and other network paths are not supported for Secure Sandbox storage.
  • Temporary or special-purpose filesystems (for example, browser caches, ephemeral tmpfs) should not be used as Storage Context roots.

Platform-specific filesystem guidance

  • Windows

    • Use NTFS or ReFS for Secure Sandbox storage volumes.
    • Do not use FAT, FAT32, exFAT, or other filesystems without NTFS/ReFS-style access control and auditing.

  • macOS

    • Use APFS for Secure Sandbox storage volumes.
    • For internal disks, APFS with FileVault is the recommended baseline.
    • Avoid using FAT/exFAT or other filesystems that do not support the required access control semantics for Secure Sandbox storage.

  • Linux

    • Use a journaling filesystem with POSIX permissions and (optionally) ACL support, such as ext4, XFS, or btrfs.
    • Avoid using FAT/exFAT, non‑journaled filesystems, or ephemeral tmpfs as Storage Context roots.

2) Encryption at rest ​

Secure Sandbox storage should be encrypted at rest according to the capabilities of the platform.

  • Windows

    • Prefer BitLocker full‑volume encryption for fixed disks, with machine or user auto‑unlock configured according to your security model.
    • Optional per-directory encryption via Windows EFS can be used for additional isolation. Consider key management and roaming implications when using EFS.

  • macOS

    • Use FileVault full‑disk encryption for internal APFS volumes that host Secure Sandbox storage.
    • For external or removable volumes, use encrypted APFS volumes or hardware‑encrypted devices.
    • Note: the macOS Launcher additionally encrypts managed Secure Sandbox storage at the application layer, using a per‑container key in the storage backing (independent of FileVault). FileVault remains recommended for defense in depth, but the managed storage is encrypted at rest even on a volume where FileVault is not enabled. As a result, posture validation on macOS does not require a FileVault check to consider managed storage encrypted at rest.

  • Linux

    • Use LUKS or an equivalent block‑level encryption technology for Secure Sandbox volumes.
    • For environments with strict requirements, enforce encryption for all volumes that host Storage Context roots.

Avoid unencrypted removable media for Secure Sandbox storage when policy requires encryption. Combine storage configuration with the removable media device policy described below.

3) Access control and permissions ​

The Secure Sandbox storage root should allow only the identities required to operate the sandbox, and no broad write access.

  • Windows (NTFS/ReFS ACLs)

    • Recommended allowlist: SYSTEM, the current user SID (or a designated service identity), and optionally local Administrators if required by your operations model.
    • Avoid broad writable principals such as Everyone, Authenticated Users, or Users.
    • Disable inheritance at the storage root and propagate explicit ACEs to child objects.
    • Review for unexpected ACEs inherited from parent folders.

  • macOS (APFS)

    • Set ownership of the storage root to the Launcher or sandbox user identity.
    • Grant write access only to that identity (and to system accounts as required) using POSIX permissions.
    • Optional ACLs can be used for finer control, but should not reintroduce broad write access (for example, everyone).

  • Linux (ext4/XFS/btrfs)

    • Set ownership of the storage root to the Launcher or sandbox user/service account.
    • Use POSIX permissions to restrict write access to that identity.
    • Optionally use POSIX ACLs, SELinux labels, or AppArmor profiles to further constrain access according to your security policies.

4) Path hardening and resolution ​

Regardless of platform:

  • Resolve environment variables and user directory shortcuts before validation.
  • Normalize the path and ensure it refers to a local filesystem path, not a network path.
  • Prefer stable identifiers for devices that may change mount points or drive letters (see platform-specific sections below).

5) Policy consistency and audit ​

  • Use enterprise configuration templates to constrain allowed Storage Context roots via allowedSourcePatterns.
  • Configure audit to fail closed, so launches are blocked when storage posture fails validation and the event is surfaced to your SIEM.

Insecure configurations should be rejected

Enterprises should configure validation to reject:

  • Unsupported or non‑compliant filesystems for Secure Sandbox storage
  • UNC/NFS/SMB or other network paths
  • Unencrypted removable media when encryption is required by policy
  • Storage roots with permissive permissions (for example, write access for Everyone/Authenticated Users/Users)
  • Sources outside enterprise allowlists

Windows volumes (including non‑C: volumes) ​

On Windows, you can place Storage Contexts on any local NTFS or ReFS volume, including non‑C: volumes, as long as the storage posture meets your security requirements.

Checklist

  • Format the target volume as NTFS or ReFS.
  • Enable BitLocker on the volume; configure auto‑unlock as needed.
  • Create a storage root (for example, D:\\TurboSandbox\\Shared).
  • Harden ACLs: SYSTEM + user/service identity (+ Administrators if required).
  • Reference the path in policy (direct path or environment variable).
  • Consider using Volume GUID paths to avoid drive‑letter churn.

Example (Global runtime; fixed D: with BitLocker; two contexts)

json
{
  "configuration": {
    "launch": {
      "runtime": {
        "files": {
          "defaultContextId": "personal",
          "contexts": [
            {
              "id": "personal",
              "label": "Personal",
              "source": "@DOCUMENTS@\\SandboxPersonal",
              "destination": "@DOCUMENTS@\\SandboxPersonal",
              "options": ["read-write"]
            },
            {
              "id": "team",
              "label": "Team Project",
              "source": "D:\\TurboSandbox\\Team",
              "destination": "@DOCUMENTS@\\SandboxTeam",
              "options": ["read-write"]
            }
          ]
        },
        "audit": {
          "settings": {
            "failurePolicy": { "onFailure": "block", "requireHealthyFor": ["all"] },
            "integrity": { "hashChain": true }
          }
        }
      }
    }
  }
}

Using an environment variable for portability

  • Set TURBO_SECURE_STORAGE=D:\\TurboSandbox\\Team on Windows (system or user scope).
json
{
  "configuration": {
    "launch": {
      "runtime": {
        "files": {
          "contexts": [
            {
              "id": "team",
              "label": "Team Project",
              "source": "%TURBO_SECURE_STORAGE%",
              "destination": "@DOCUMENTS@\\SandboxTeam",
              "options": ["read-write"]
            }
          ]
        }
      }
    }
  }
}

Enterprise template constraints (recommended)

  • Constrain to allowed sources via regex/glob patterns (examples):
    • ^D:\\\\TurboSandbox\\\\Team($|\\\\.*)
    • ^\\\\\\\\\\\\\\?\\\\Volume\{[0-9A-Fa-f-]+\}\\\\TurboSandbox\\\\Team($|\\\\.*)
  • See: Configuration Templates

Volume GUID paths (stable identifiers on Windows) ​

On devices where drive letters can change (for example, docking stations, removable SSDs), prefer Volume GUID paths on Windows:

  • Example path: \\?\Volume{1f23c9c1-…}\\TurboSandbox\\Shared
  • Advantage: Binds to the specific volume independent of drive letter.

Example configuration using a volume GUID path

json
{
  "configuration": {
    "launch": {
      "runtime": {
        "files": {
          "contexts": [
            {
              "id": "secureShared",
              "label": "SecureShared",
              "source": "\\\\?\\Volume{1f23c9c1-0000-0000-0000-000000000000}\\TurboSandbox\\Shared",
              "destination": "@DOCUMENTS@\\SandboxShared",
              "options": ["read-write"]
            }
          ]
        }
      }
    }
  }
}

macOS Volumes and External Disks ​

On macOS, Secure Sandbox storage should live on APFS volumes that meet your encryption and access control requirements.

Common patterns

  • Place per‑user storage under the user’s home directory, for example: /Users/<user>/TurboSandbox/Shared.
  • For larger deployments, use a dedicated APFS volume that is mounted at a stable mount point (for example, /Volumes/SecureSandbox).

Checklist

  • Use APFS for volumes that host Storage Context roots.
  • Enable FileVault for internal system volumes and for external APFS volumes where policy requires encryption.
  • Set ownership of the storage root to the Launcher or sandbox user identity.
  • Restrict write permissions to that identity and required system accounts.

Example configuration (per‑user directory)

json
{
  "configuration": {
    "launch": {
      "runtime": {
        "files": {
          "contexts": [
            {
              "id": "personal",
              "label": "Personal",
              "source": "~/TurboSandbox/Personal",
              "destination": "@DOCUMENTS@/SandboxPersonal",
              "options": ["read-write"]
            }
          ]
        }
      }
    }
  }
}

Linux volumes and external disks ​

On Linux, Secure Sandbox storage should live on a local journaling filesystem with strong access control and, where required, encryption.

Common patterns

  • Place storage under a dedicated application directory, for example: /var/lib/turbo/sandbox.
  • Use a dedicated encrypted volume mounted at a stable mount point, for example: /mnt/secure_sandbox.

Checklist

  • Use ext4, XFS, btrfs, or another journaling filesystem that meets your requirements.
  • Use LUKS or equivalent encryption for volumes that host Storage Context roots when policy requires encryption.
  • Set ownership of the storage root to the Launcher or sandbox user/service account.
  • Restrict write access via POSIX permissions and, optionally, ACLs or security modules (SELinux, AppArmor).

Example configuration (dedicated mount point)

json
{
  "configuration": {
    "launch": {
      "runtime": {
        "files": {
          "contexts": [
            {
              "id": "secureShared",
              "label": "SecureShared",
              "source": "/mnt/secure_sandbox/shared",
              "destination": "@DOCUMENTS@/SandboxShared",
              "options": ["read-write"]
            }
          ]
        }
      }
    }
  }
}

Removable media (enforced encryption and allowlists) ​

If your storage resides on removable media, combine device policy with storage configuration. The device controls and encryption requirements apply across platforms; the way devices are matched is platform‑specific.

Policy example (restricted removable media with encryption and device allowlist)

json
{
  "configuration": {
    "launch": {
      "runtime": {
        "devices": {
          "removableMedia": {
            "mode": "restricted",
            "encryptionRequired": true,
            "allowedDevices": [
              {
                "matchType": "hardwareId",
                "pattern": "USB\\\\VID_1234&PID_5678\\\\ABCDEF",
                "patternType": "exact"
              }
            ]
          }
        },
        "files": {
          "contexts": [
            {
              "id": "secureShared",
              "label": "SecureShared",
              "source": "\\\\?\\Volume{1f23c9c1-0000-0000-0000-000000000000}\\TurboSandbox\\Shared",
              "destination": "@DOCUMENTS@\\SandboxShared",
              "options": ["read-write"]
            }
          ]
        }
      }
    }
  }
}

Notes

  • On Windows, match removable devices by hardware ID, certificate thumbprint (64‑hex SHA‑256 or 40‑hex SHA‑1), or vendor ID.
  • On macOS, match removable devices using properties exposed via I/O Kit (for example, vendor ID, product ID, serial number) according to how your environment maps those properties into allowedDevices.
  • On Linux, match removable devices using udev properties (for example, ID_VENDOR, ID_MODEL, ID_SERIAL, ID_PATH) according to how your environment maps those properties into allowedDevices.
  • Enforce encryptionRequired: true when you require encryption for any removable volume that hosts Secure Sandbox storage.
  • Constrain allowed sources via enterprise templates.

Runtime posture checks (validation) ​

The Launcher or Sandbox Manager validates storage posture at startup and/or pre‑launch. These checks run per Storage Context and apply consistently across Windows, macOS, and Linux, with platform‑specific details.

Recommended checks (performed per context):

  • Path resolution and normalization

    • Resolve environment variables; compute the canonical path.
    • Reject UNC/NFS/SMB and other network paths.
    • Ensure the path exists (or can be created under a secure root).

  • Filesystem checks

    • On Windows, verify the volume uses NTFS or ReFS.
    • On macOS, verify the volume uses APFS.
    • On Linux, verify the filesystem is a supported journaling filesystem (for example, ext4, XFS, or btrfs) according to your policy.

  • Encryption checks

    • On Windows, verify BitLocker protection is enabled for volumes that require encryption; if EFS is used, verify the folder is encrypted and the user has access to the key.
    • On macOS, verify FileVault or APFS volume encryption is enabled when required.
    • On Linux, verify that the volume is mounted via an encrypted mapping (for example, LUKS) when required.

  • Permission and access control checks

    • On Windows, ensure there is no write access for broad principals (Everyone/Authenticated Users/Users), and that ACLs explicitly allow only SYSTEM, the launcher user/service identity, and any required administrative accounts.
    • On macOS and Linux, ensure ownership and POSIX permissions restrict write access to the sandbox user/service account and required system identities.

  • Policy conformance

    • Each files.contexts[].source should match enterprise template allowedSourcePatterns.

  • Audit and failure behavior

    • When configured to fail closed, the runtime blocks launches on posture failures and emits an audit record.
    • When configured to warn only, the runtime surfaces a warning and emits an audit record with an appropriate classification (for example, postureNonCompliant).

Example user‑visible errors

  • “Secure Sandbox storage path rejected: filesystem or encryption settings do not meet policy requirements.”
  • “Removable media encryption is required by policy but was not detected for the target volume.”
  • “Storage directory permissions allow write access for a broad group, which is disallowed by policy.”

See also

Turbo.net © 2025