Appearance

Runtime Configuration ​

Central reference for the runtime object used by the Launcher. The runtime governs on‑device Secure Sandbox behavior, optional remote placement controls, device access, data motion, incident response, and audit.

What You'll Learn

  • Where runtime can be defined and how precedence works
  • Placement & isolation (on‑device Secure Sandbox vs optional Remote Placement)
  • Devices (printers, removable media, bluetooth, NFC)
  • Data motion (clipboard, screen capture/sharing)
  • Files shared storage
  • Incident response and audit

1. Where Runtime Can Be Defined ​

  • Global (applies to all launches): configuration.launch.runtime
  • Per‑app (applies when that app launches): apps[].modifications.runtime
  • Per‑launch profile (applies only when that profile is selected): apps[].profiles[].runtime

Precedence and merge behavior: See Merging & Precedence.

2. Terminology ​

  • Secure Sandbox: The on‑device privileged area where applications run by default with isolation and DLP controls enforced locally.
  • Remote Placement: Optional remote execution context. When used, it must comply with the sovereignty and placement policies you configure. Secure Sandbox remains on‑device; remote placement does not change that default behavior.

3. Placement & Isolation (runtime.isolation) ​

Purpose

  • Control optional remote placement behavior subject to sovereignty constraints. Applications run on‑device in the Secure Sandbox by default; these settings only apply when remote placement is enabled.

Keys

  • isolation.remoteSandbox (boolean): Enables remote placement. Default: false.
  • isolation.remoteSandboxConfig.enforceSovereignty (boolean): When true, placement must be within approved sovereign regions.
  • isolation.remoteSandboxConfig.allowedRegions (string[]): Approved region identifiers (e.g., "aws-us-gov-west-1", "azure-us-gov-virginia").
  • isolation.remoteSandboxConfig.onPlacementFailure (enum): "denyLaunch" | "fallbackToLocal" | "auditOnly".

Behavior

  • If remoteSandbox is false: All launches occur on‑device in the Secure Sandbox; remoteSandboxConfig is ignored.
  • If remoteSandbox is true:
    • With enforceSovereignty: true, the target placement must be within allowedRegions.
    • onPlacementFailure:
      • denyLaunch: Do not launch if sovereign‑compliant placement is unavailable.
      • fallbackToLocal: Launch on‑device in the Secure Sandbox instead.
      • auditOnly: Proceed with normal behavior; record an audit event if sovereign requirements cannot be satisfied.

Security notes

  • Use sovereign enforcement to ensure optional remote execution adheres to regulated requirements. When remote placement is not used, all enforcement occurs locally within the Secure Sandbox.

Example (Global; sovereign remote placement with deny on failure)

json
{
  "configuration": {
    "launch": {
      "runtime": {
        "isolation": {
          "remoteSandbox": true,
          "remoteSandboxConfig": {
            "enforceSovereignty": true,
            "allowedRegions": ["aws-us-gov-west-1", "azure-us-gov-virginia"],
            "onPlacementFailure": "denyLaunch"
          }
        }
      }
    }
  }
}

4. Devices (runtime.devices) ​

Purpose

  • Govern which devices are visible/usable inside the on‑device Secure Sandbox to align with DLP and CMMC MP controls.

Keys

  • printers: "disabled" | "virtual-only" | "host-allowed"
  • removableMedia:
    • mode: "block" | "readOnly" | "restricted" | "allowed"
    • encryptionRequired: boolean
    • allowedDevices (array of matchAll rules):
      • matchType: "hardwareId" | "certificateThumbprint" | "vendorId"
      • pattern: string
      • patternType: "exact" | "regex" | "glob"
  • bluetooth: "enabled" | "disabled"
  • nfc: "enabled" | "disabled"

Notes

  • Prefer system‑wide (global) policy for enterprise enforcement so user policy cannot re‑enable sensitive devices.
  • Device matchAll rules follow the same pattern semantics used elsewhere in policy (exact/regex/glob). For matchType: "certificateThumbprint", patterns must be 64-hex (SHA-256) or 40-hex (SHA-1).
  • For vendor‑specific controls, prefer structured keys or runtime.extensions.{vendor}; avoid raw flags.
  • On Windows, hardwareId typically corresponds to USB/PCI device identifiers (for example, USB\\VID_XXXX&PID_YYYY\\SERIAL).
  • On macOS and Linux, environments can map I/O Kit or udev properties into allowedDevices patterns to achieve similar allowlisting behavior for removable storage.

Example (Global; restricted removable media with encryption and allow‑list)

json
{
  "configuration": {
    "launch": {
      "runtime": {
        "devices": {
          "printers": "virtual-only",
          "removableMedia": {
            "mode": "restricted",
            "encryptionRequired": true,
            "allowedDevices": [
              {
                "matchType": "hardwareId",
                "pattern": "USB\\\\VID_XXXX&PID_YYYY\\\\SERIAL",
                "patternType": "exact"
              }
            ]
          },
          "bluetooth": "disabled",
          "nfc": "disabled"
        }
      }
    }
  }
}

Per‑app override (read‑only media with certificate allow‑list)

json
{
  "apps": [
    {
      "id": "chrome",
      "modifications": {
        "runtime": {
          "devices": {
            "removableMedia": {
              "mode": "readOnly",
              "encryptionRequired": true,
              "allowedDevices": [
                {
                  "matchType": "certificateThumbprint",
                  "pattern": "5E0B1B36A6F3D1C2A6C9E4B1A46C9D18B1E3F2A469C7BA0E8F1A2B3C4D5E6F70",
                  "patternType": "exact"
                }
              ]
            }
          }
        }
      }
    }
  ]
}

See also

5. Data Motion (runtime.dataMotion) ​

Purpose

  • Control clipboard, drag‑and‑drop, and screen capture/sharing from the runtime. Use hard‑switch settings to enforce baseline posture, then add priority rules to allow/deny/process specific transfers via declarative pipelines.

Keys

  • dataMotion.settings:
    • Channels like clipboard, screenCapture, etc., each with enabled and channel‑specific options (e.g., watermark for screen capture).
  • dataMotion.rules:
    • Rule list with id, channel, direction, match (e.g., by classification), and action (allow, deny, process).

Example (classification‑aware deny and dynamic watermark)

json
{
  "configuration": {
    "launch": {
      "runtime": {
        "dataMotion": {
          "settings": {
            "clipboard": { "enabled": true, "defaultAction": "deny" },
            "screenCapture": {
              "enabled": true,
              "watermark": {
                "text": "CUI // SP-CTI\\n{User.UPN} @ {Timestamp.UTC}",
                "opacity": 0.3,
                "persistent": true,
                "style": "diagonalRepeating"
              }
            }
          },
          "rules": [
            {
              "id": "clip-deny-cui-itar-out",
              "channel": "clipboard",
              "direction": "out",
              "match": { "classifications": { "normalized": ["CUI", "ITAR"] } },
              "action": { "type": "deny" }
            }
          ]
        }
      }
    }
  }
}

See also

6. Files Storage (runtime.files) ​

Purpose

  • Define one or more Storage Contexts used by the Files tab. The selected Storage Context sets the Files tab root; users cannot navigate above this root. These values are authored under runtime (not under configuration.launch.mounts). For a side-by-side comparison of Files tab Storage Contexts vs structured mounts, see Storage Contexts vs Structured Mounts.

Keys

  • files.contexts: array of Storage Context objects. Each context has:
    • id (string): unique identifier.
    • label (string): user-visible name.
    • source (string): local filesystem path or token-resolved path for the host side.
    • destination (string): container path inside the runtime.
    • options (array): ["read-write" | "read-only"].
    • icon (string, optional): icon reference for the context picker UI.
    • visibility (object, optional): gates exposure in the picker.
      • abac (object, optional): authorization requirements evaluated at runtime.
      • os (string[], optional): restrict to specific operating systems ["windows" | "macos" | "linux"].
  • files.defaultContextId (string, optional): selects the initially active context; if omitted, the first visible context is used.

Behavior

  • The Files tab is available when at least one Storage Context is defined and valid. After fixing configuration, use the Files tab "Retry" to reload.

Accessing Cloud Storage ​

To surface OneDrive, Dropbox, and SMB shares inside application containers, use Turbo Drive with structured mounts. Storage Contexts are reserved for local Secure Sandbox storage volumes; cloud storage should be exposed through Turbo Drive mounts instead of being configured directly as Storage Context roots.

Map provider folders from Turbo Drive (for example, T:\\OneDrive, T:\\Dropbox, T:\\SMB or the platform‑specific Turbo Drive mount point) into containers via policy-authored mounts.

See: Cloud Storage Integration and Mounts & Shared Storage.

Security & Placement ​

  • Configure each context’s source to resolve to a directory on a local Secure Sandbox storage volume. The volume and directory should meet the filesystem, encryption, and access control requirements for the platform.
  • Do not use UNC/NFS/SMB or other network paths as Storage Context roots.
  • Avoid unsupported or temporary filesystems (for example, FAT/exFAT or ephemeral tmpfs) for Secure Sandbox storage.
  • On Windows, use NTFS or ReFS volumes with BitLocker (and optionally EFS) according to your policy.
  • On macOS, use APFS volumes with FileVault or APFS volume encryption as required.
  • On Linux, use journaling filesystems such as ext4, XFS, or btrfs, and use LUKS or equivalent encryption when required by policy.
  • See complete guidance: Secure Sandbox Storage

Example (configuration shape)

json
{
  "configuration": {
    "launch": {
      "runtime": {
        "files": {
          "defaultContextId": "personal",
          "contexts": [
            {
              "id": "personal",
              "label": "Personal",
              "source": "<SECURE_LOCAL_PATH>",
              "destination": "@DOCUMENTS@\\SandboxPersonal",
              "options": ["read-write"]
            }
          ]
        }
      }
    }
  }
}

Use platform-appropriate values for <SECURE_LOCAL_PATH> (for example, a local Documents subfolder or a path on a Secure Sandbox volume). For multi-context setups and advanced patterns such as volume GUID paths on Windows, see Secure Sandbox Storage and Mounts & Shared Storage.

Runtime Posture Checks ​

Recommended validations performed by the Launcher or Sandbox Manager (per context):

  • Resolve and normalize the source path; reject UNC/NFS/SMB and other network paths.
  • Verify the filesystem and encryption posture according to platform requirements:
    • On Windows, verify NTFS or ReFS and check BitLocker/EFS state if required.
    • On macOS, verify APFS and FileVault or APFS encryption state if required.
    • On Linux, verify a supported journaling filesystem (for example, ext4, XFS, or btrfs) and encrypted mapping (for example, LUKS) if required.
  • Verify permissions are hardened so that only the launcher user/service and required system identities have write access; avoid broad write access for general user groups.
  • Enforce enterprise template allowlists (for example, allowedSourcePatterns).

Failure behavior is controlled by audit failure policy. In most deployments, fail‑closed is preferred so posture failures block launches and are surfaced to your SIEM. See troubleshooting guidance: Files Troubleshooting

See also

7. Incident Response and Forensics (runtime.incidentResponse) ​

Purpose

  • Define EDR/XDR integration and automated forensic capture policies initiated from the on‑device Secure Sandbox.

Keys

  • incidentResponse.edrIntegration: "enabled" | "disabled"
  • incidentResponse.forensicCapturePolicy:
    • trigger: "disabled" | "manual" | "onThreatDetect" | "onPolicyViolation"
    • captureTypes: enum list (e.g., "diskSnapshot", "memoryDump")
    • captureDestinationRef: Reference to a secure destination (e.g., a sovereign storage locator)

Example (Global; enable EDR and capture on threat detect)

json
{
  "configuration": {
    "launch": {
      "runtime": {
        "incidentResponse": {
          "edrIntegration": "enabled",
          "forensicCapturePolicy": {
            "trigger": "onThreatDetect",
            "captureTypes": ["diskSnapshot", "memoryDump"],
            "captureDestinationRef": "secure-forensics-s3-govcloud"
          }
        }
      }
    }
  }
}

Operational notes

  • Use enterprise‑approved destinations for forensic capture to meet regulatory and residency requirements.
  • Combine with audit configuration to record triggers and capture outcomes.

8. Audit Trails (runtime.audit) ​

Purpose

  • Configure security‑relevant logging to meet CMMC/NIST/ITAR needs. Use integrity controls (hash chains, RFC3161 timestamping), failure policy (fail closed), and export settings for SIEM forwarding and immutable retention hints.

Scope

  • Audit is global only. Configure at configuration.launch.runtime.audit. Per‑app and per‑profile overrides are not supported.

Example (fail‑closed with RFC3161 and SIEM forwarding)

json
{
  "configuration": {
    "launch": {
      "runtime": {
        "audit": {
          "settings": {
            "integrity": {
              "hashChain": true,
              "timestamping": { "mode": "rfc3161", "tsaUrl": "http://timestamp.provider.com" }
            },
            "failurePolicy": {
              "onFailure": "block",
              "requireHealthyFor": ["all"]
            },
            "export": {
              "mode": "siemForwarding",
              "deliveryGuarantee": "atLeastOnceConfirmed",
              "complianceMetadata": { "retentionPolicyRef": "WORM_7Y" }
            }
          }
        }
      }
    }
  }
}

See also

Turbo.net © 2025