Policy System

This section describes the Turbo Launcher policy model, including global configuration, authorization and visibility, matchers, modifications, launch profiles, merging, and variable substitution.

What You'll Learn

• How the Launcher policy file is structured and layered
• How to author authorization/visibility rules, matchers, and modifications
• How to manage profiles, precedence, and variable substitution

---

1. Policy Overview

Turbo Launcher uses a JSON-based allowlist policy:

• Only applications and operations that match explicit allow rules are permitted.
• The Policy System adds identity/SSO integration, cryptography and host posture, and classification-aware DLP.
• Policy can be signed and validated using certificate thumbprints.

Simplified top-level structure. Use this layout as the starting point when you author or review policy files: configuration establishes global defaults, apps define per-application behavior, and the remaining sections control file handling.

{
  "policySignature": "...",
  "signatureCertificateThumbprints": ["..."],
  "configuration": { /* global settings */ },
  "configurationTemplates": [ /* enterprise templates */ ],
  "apps": [ /* application policies */ ],
  "fileTypes": [ /* file type definitions */ ],
  "fileAssociations": [ /* routing */ ],
  "files": [ /* file operation policies */ ]
}

See: Launcher Policy Overview

---

2. Global Configuration

Global configuration aggregates identity, security posture, classification, and default runtime settings across all launches.

Key responsibilities:

• Identity & SSO defaults
• Classification definitions
• Runtime defaults (placement, devices, dataMotion, audit)
• Global networking and trust configuration

See: Global Configuration

---

3. Authorization and Visibility

Application visibility and launch authorization are controlled by apps[] entries.

Important fields:

• apps[].matchAll / apps[].matchAny – How shortcuts / discovery records are matched (targetPath, publisherCertificate, fileHash, version, tags, etc.).
• apps[].action – "allow" or "deny".
• apps[].visibility – "visible" or "hidden".
• apps[].authorization.requirements – ABAC requirements on user attributes and context.

Notes:

• Hidden apps remain eligible as association targets (for example, Open With) but are not listed in the Applications tab.
• ABAC requirements can use normalized user attributes (such as department, role, usPersonStatus) and context constraints (such as allowedGeos, requireCompliantHost).

See: Authorization & Visibility

---

4. Matchers and Patterns

Matchers define how discovered applications and files are bound to policy rules.

Common matcher types:

• targetPath – Executable or shortcut target path.
• publisherCertificate – Signing certificate identity.
• fileHash – Explicit binary hash.
• version – Version constraints.
• Additional types as defined in the schema.

Pattern types:

• exact
• glob
• regex

Recommendations:

• Use publisherCertificate and fileHash where possible for high assurance.
• Combine matchers to constrain by version or install location for sensitive apps.

See: Matchers & Patterns

---

5. Modifications, Flags, and Arguments

apps[].modifications lets you tailor how allowed applications are launched:

• Add or override Turbo flags (configuration.launch.flags and per-app overrides).
• Set or append command-line arguments.
• Provide per-app runtime, mounts, and identityAccess overrides.

Arguments and flags are merged according to precedence rules (global → app → profile) and may include variable substitution tokens.

See:

• Modifications & Flags
• Application Arguments

---

6. Launch Profiles

Launch profiles define named variants for a given application (for example, Incognito, Diagnostic mode, Extensions Disabled).

Structure:

• apps[].profiles[].id – Stable identifier (kebab-case, unique within the app).
• apps[].profiles[].label – UI label.
• Optional runtime, mounts, flags, and arguments overrides.

Profiles are merged on top of global and app-level policy, allowing per-profile:

• Different network or DLP posture
• Different Turbo Drive mounts
• Additional or modified arguments

See: Launch Profiles

---

7. Merging and Precedence

Policy configuration is layered and merged from multiple scopes:

1. Global – configuration.*
2. App – apps[].modifications.*
3. Profile – apps[].profiles[].*

Merging rules determine how arrays and objects are combined for:

• Runtime (isolation, devices, dataMotion, files, incidentResponse, audit)
• Mounts
• Flags and arguments
• File policies

Administrators should consult the detailed precedence rules before combining multiple policy sources or delegating authoring.

See: Merging & Precedence

---

8. Variable Substitution

Variables allow dynamic injection of values into policy before it is delivered to the Launcher.

Typical uses:

• Hiding credentials (for example, proxy auth) behind CRED lookups.
• Injecting environment values or host-specific identifiers.

Example (global proxy flag using Windows Credential Manager):

{
  "configuration": {
    "launch": {
      "flags": [
        "--proxy-server=socks5://{{CRED:PolicyProxy001:username}}:{{CRED:PolicyProxy001:password}}@proxy.corporate.local:1081"
      ]
    }
  }
}

Credentials setup on Windows:

cmdkey /generic:"turbo:PolicyProxy001" /user:"proxyuser" /pass:"SecurePass123!"
cmdkey /list | findstr "turbo"

Notes:

• Variable resolution is performed by Sandbox Manager before policy reaches the Launcher.
• If resolution fails (for example, missing credential), variables resolve to empty strings and dependent features (like authenticated proxies) may fail.

See: Variable Substitution

---

9. Related Topics

• Global Configuration
• Security Best Practices
• Audit Trails
• Identity Access (SSO)