Constrained Language Mode profiles for SPE remoting security

[michaellwest]

Summary

Predefined Constrained Language Mode (CLM) profiles and configuration for securing SPE remoting endpoints. Based on an audit of all 291 serialized PowerShell scripts across the release/9.0 branch, this proposal catalogs every .NET API, Sitecore library, function, and cmdlet in use, then defines tiered restriction profiles, a script trust model, and a hybrid config/item-based management system.

Scope: Remoting endpoints only (/api/spe/remoting, RESTful v2, custom web API services). ISE, Console, context menus, ribbons, pipelines, event handlers, and scheduled tasks remain unchanged at FullLanguage.

---

1. API & Cmdlet Catalog

Dangerous Patterns Identified

Pattern	Location	Risk
Reflection with nonpublic BindingFlags	Remoting.yml, Remoting2.yml	Bypasses access control
[scriptblock]::Create()	Rules Based Report.yml	Dynamic code execution
Add-Type -AssemblyName	Expand-Archive.yml	Assembly loading
Direct SQL via SqlClient	Invoke-SqlCommand.yml	Database access
[System.Web.Security.Membership]	Enforce password expiration.yml	Identity manipulation

Not found (good): Invoke-Expression, Start-Process, Add-Type -TypeDefinition, Add-Type -Path

Full catalog of .NET APIs, Sitecore APIs, SPE cmdlets, and standard PowerShell cmdlets available in the design document.

---

2. Restriction Profiles

Four tiered profiles combining PowerShell's native LanguageMode with SPE's commandRestrictions. All profiles are opt-in -- fully backward-compatible.

Profile: unrestricted (Default)

• LanguageMode: FullLanguage
• Command Restrictions: None
• Use case: Trusted admin scripts, development environments

Profile: read-only-sitecore

• LanguageMode: ConstrainedLanguage
• Blocked: Set-Item, Remove-Item, New-Item, Move-Item, Copy-Item, Rename-Item, Publish-Item, Protect-Item, Unprotect-Item, Install-Package, New-Package, Set-Layout, Add-Rendering, Remove-Rendering
• Allowed .NET Types: Primitives only ([int], [string], [bool], [DateTime], [guid], [regex])
• Use case: Reporting integrations, dashboards, monitoring

Profile: read-only-full

• Extends: read-only-sitecore`
• Additional blocks: Invoke-SqlCommand, Set-Content, Out-File, Export-Csv, Export-Clixml, Add-Type, Compress-Archive, Expand-Archive, Send-SheerMessage
• Blocked .NET Types: All non-primitive types (via CLM)
• Blocked Patterns: [System.IO.File]::Write*, [System.Data.SqlClient.*]
• Use case: Untrusted external consumers, third-party integrations

Profile: content-editor

• LanguageMode: ConstrainedLanguage
• Mode: Allowlist
• Allowed: All read cmdlets from read-only-sitecore + Set-Item (content fields only), Publish-Item, New-Item (content items only), Lock-Item, Unlock-Item
• Standard fields (__ prefix) blocked by default -- only content fields (defined on the item's own template) are writable. Admins can allowlist specific standard fields via config.
• Use case: Content management APIs, headless CMS integrations

Profile Inheritance

Single-level only (e.g., read-only-full extends read-only-sitecore). Resolved via load-time flattening -- the ProfileManager merges parent + child blocklists at config load into a flat RestrictionProfile object. No runtime chain-walking.

Add-Type Handling

Block Add-Type entirely in constrained profiles with configurable assembly allowlist:

• Allowed: System.IO.Compression, System.IO.Compression.FileSystem
• Always blocked: -TypeDefinition (compiles C#), -Path (loads DLLs), -MemberDefinition (P/Invoke)

SQL Access

Block Invoke-SqlCommand entirely in constrained profiles. If SQL read access is needed, a future Invoke-SqlQuery cmdlet wrapping ExecuteReader only is safer than parsing SQL strings.

File System

• read-only-sitecore: Allow file reads, block file writes
• read-only-full: Block all direct file system .NET calls; allow only Get-Content, Test-Path, Resolve-Path, Get-ChildItem

---

3. Trusted Scripts Model

Problem

SPE scripts use Import-Function, Invoke-Script, and Execute-Script to load Script Library items. These often require .NET type access that CLM blocks. A blanket CLM enforcement would break most SPE built-in functionality.

Solution: GUID + Content Hash Trust Registry

Trust operates on script items (not individual function names) since a single script item (e.g., DialogBuilder) can define multiple functions.

<trustedScripts>
  <script name="Remoting"
          itemId="{E5F6A7B8-...}"
          contentHash="sha256:..."
          trust="System"
          allowTopLevel="true">
    <exports>
      <function>ConvertTo-CliXml</function>
      <function>ConvertFrom-CliXml</function>
    </exports>
  </script>

  <script name="DialogBuilder"
          itemId="{B3E2F1A2-...}"
          contentHash="sha256:..."
          trust="Trusted">
    <exports>
      <function>New-DialogBuilder</function>
      <function>Add-DialogField</function>
      <function>Show-Dialog</function>
    </exports>
  </script>
</trustedScripts>

Trust Levels

1. Untrusted (default) -- runs under caller's language mode and command restrictions
2. Trusted -- can use .NET types and CLM bypass; no reflection access
3. System -- reflection + private member access allowed; config-only assignment

Why GUIDs

• Sitecore item GUIDs are assigned at creation and never change (survive renames, moves, serialization)
• SPE ships Script Library items via serialization with fixed GUIDs
• Cannot create a new item with the same GUID -- Sitecore enforces uniqueness
• Prevents shadowing: a user-created script with the same name but different GUID will not get trust elevation

Content Hash Integrity

SHA256 of the script body stored alongside the trust entry. Catches tampering or accidental modification.

<script name="..."
        itemId="{...}"
        contentHash="sha256:abc123..."
        trust="Trusted"
        onHashMismatch="constrain" />  <!-- or "block" or "warn" -->

Execution Entry Points

Trust applies at the common execution layer, not per-cmdlet:

Method	Trust Check	Export Manifest
Import-Function	GUID + hash	Yes -- controls which functions get elevated status
Invoke-Script	GUID + hash	No -- return values subject to caller's type restrictions
Execute-Script (internal)	GUID + hash (remoting only)	Context-dependent

Export Manifest (Import-Function only)

When a trusted script is loaded via Import-Function:

1. Script body executes in FullLanguage (defines functions)
2. Functions actually defined are compared against declared <exports>
3. Undeclared functions are either removed (strict) or forced constrained (permissive)
4. Prevents a compromised script from injecting elevated functions that shadow built-ins

Resolution Order

In constrained sessions, Import-Function always prefers the GUID-registered script over a name match, preventing shadowing.

Auto-Generation

A build task parses serialized YAML files to auto-generate <trustedScripts> with correct GUIDs, content hashes, and export lists (via AST parsing of function definitions).

---

4. Scope Claim Integration

JWT scope claims map to profile names:

• scope=read-only-sitecore applies that profile
• scope=content-editor applies that profile
• No scope or unknown scope falls back to service default
• Multiple scopes: most restrictive wins (intersection)

Builds on the existing scopeRestrictions system in ScriptValidator.cs.

---

5. Audit Logging

Configurable per profile:

Level	What's Logged
None	No logging
Violations	Blocked commands, denied .NET types, failed trust checks
Standard	Violations + script execution start/end with user context
Full	Standard + every command executed with arguments

Pipeline scripts (LoggedIn, LoggingIn, Logout) always run in FullLanguage and are logged with [INFO] Pipeline script executing in FullLanguage (exempt from profile restrictions).

---

6. Hybrid Configuration Model

Base Configuration (Spe.config)

Profiles defined as XML patches. Ship with SPE, provide secure defaults. All services default to unrestricted.

Item-Based Overrides (Phase 2)

Admins extend/override via Sitecore items under /sitecore/system/Modules/PowerShell/Settings/Restriction Profiles/. Merge behavior: most restrictive wins.

---

7. Migration & Backward Compatibility

All new functionality is opt-in. Existing installations see no behavior change.

Phased Rollout

1. Phase 1: RestrictionProfile class, config loading with load-time flattening, service-to-profile mapping, command blocklist/allowlist enforcement, GUID-based script trust registry, violations-level audit logging, standard field blocking for content-editor, JWT scope-to-profile mapping
2. Phase 2: Item-based overrides, Restriction Profile Override template, enhanced trust management UI
3. Phase 3: AST-based function classification (ReadOnly/WriteCapable/Elevated), content hash auto-generation in build
4. Phase 4: Documentation and migration guide

Adoption

One attribute change per service:

<remoting enabled="true" requireSecureConnection="true" profile="read-only-sitecore" />

---

8. New Components

Component	Purpose
RestrictionProfile	Data model: name + language mode + command restrictions + trust config + audit level
ProfileManager	Config loading, inheritance flattening, caching
TrustedScriptEntry	GUID + content hash + trust level + export manifest
ScriptTrustRegistry	Trust lookup by item GUID at execution time
Extended ScriptValidator	Enforce profile restrictions during script execution
Extended WebServiceSettings	Map services to profiles

Performance

• Profile resolution cached per service+scope combination
• AST analysis cached per script revision
• Trust lookups by GUID (O(1) dictionary)
• All caches respect existing Spe.AuthorizationCacheExpirationSecs and Spe.WebApiCacheExpirationSecs

---

Design Decisions

Decision	Choice	Rationale
Profile inheritance depth	Single level only	Avoids merge-order ambiguity
Inheritance resolution	Load-time flattening	Simpler, faster than runtime chain-walking
Trust identity	Item GUID + content hash	GUIDs are immutable and unique; hash catches tampering
SQL in constrained profiles	Block entirely	Safer than parsing SQL strings; future Invoke-SqlQuery cmdlet for read-only access
Temporary remoting elevation	Not supported	Use separate endpoints with different profiles instead
AST analysis timing	Sync on first request, cached	Pre-analysis on save misses scripts modified outside Sitecore
Composable scopes	Intersection only	Union would defeat the purpose of restrictions
Standard fields in content-editor	Blocked by default (__ prefix)	Prevents security/workflow/rendering tampering; allowlist for exceptions

[michaellwest]

Update: Flat Profiles (No Inheritance) + Profile Renaming

Decision: Drop extends, ship flat profiles

Sitecore's config patching system (patch:insert, patch:delete, patch:attribute, etc.) is itself an inheritance/merge system. Adding a second extends-based inheritance on top creates ambiguity:

• Problem 1: A customer patches the "parent" profile (e.g., adds a blocked command to read-only). The "child" profile should inherit this, but our flattening runs after patching -- so this works. However, the reverse is confusing: a customer patch:deletes a command from the child profile's blocklist, but flattening pulls it back in from the parent. There's no way to distinguish "intentionally removed" from "never present in the child."

• Problem 2: Nothing prevents customers from chaining extends multiple levels deep, violating the single-level constraint. We'd need to error or silently ignore -- both surprising.

• Problem 3: Sitecore admins already know config patching. A second, different composition system creates confusion about which to use and how they interact.

Resolution: All shipped profiles are fully self-contained (no extends attribute). Each profile lists every blocked/allowed command explicitly. Customers customize using standard Sitecore config patching:

<!-- Customer adds a blocked command -->
<profile name="read-only">
  <commandRestrictions>
    <blockedCommands>
      <command patch:after="*[last()]">My-DangerousCommand</command>
    </blockedCommands>
  </commandRestrictions>
</profile>

<!-- Customer removes a blocked command -->
<profile name="read-only">
  <commandRestrictions>
    <blockedCommands>
      <command patch:delete="">Add-Type</command>
    </blockedCommands>
  </commandRestrictions>
</profile>

<!-- Customer creates a new custom profile (fully flat) -->
<profile name="custom-reporting" languageMode="ConstrainedLanguage">
  <commandRestrictions mode="blocklist">
    <blockedCommands>
      <command>Set-Item</command>
      <command>Remove-Item</command>
      <!-- ... explicit list ... -->
    </blockedCommands>
  </commandRestrictions>
</profile>

This makes ProfileManager trivially simple: read each <profile> element, build a RestrictionProfile object. No merge logic, no ordering concerns.

The ~15 commands of duplication between read-only and read-only-strict is a small price for eliminating an entire class of merge-order bugs.

---

Profile Renaming

Old Name	New Name	Rationale
read-only-sitecore	read-only	Cleaner base name; "sitecore" was redundant since all profiles operate on Sitecore
read-only-full	read-only-strict	"full" was ambiguous; "strict" clearly communicates tighter restrictions

Final profile set:

• unrestricted -- current default behavior, no restrictions
• read-only -- blocks write cmdlets, allows primitives only via CLM
• read-only-strict -- blocks SQL, file system, Add-Type, assembly loading on top of read-only restrictions
• content-editor -- allowlist mode for content management operations

[michaellwest]

Update: Module Loading Restrictions

Gap Identified

Command blocklists/allowlists operate on command names, but Import-Module can bring in entirely new commands that aren't on any list. Additionally, PowerShell auto-loads modules when you call a command from a module in $env:PSModulePath, so a command not on the blocklist could resolve to an installed module's cmdlet automatically.

Solution: Three Controls

1. Block Import-Module in all constrained profiles

SPE's own functionality uses Import-Function (Script Library), not Import-Module (PowerShell modules). There is no legitimate remoting use case for loading arbitrary PowerShell modules.

2. Restrict module auto-loading

Set $PSModuleAutoloadingPreference = "None" at session creation for constrained profiles. This prevents bypassing the blocklist via module auto-discovery. Commands only work if they're already loaded in the session.

3. Allowlist pre-loaded modules per profile

Each profile declares which modules are loaded into the session at startup. Commands from these modules (and only these) are available, then filtered through the command blocklist/allowlist:

<profile name="read-only" languageMode="ConstrainedLanguage"
         auditLevel="Violations">
  <modules autoload="None">
    <!-- Only these modules are available -->
    <module>Microsoft.PowerShell.Core</module>
    <module>Microsoft.PowerShell.Utility</module>
    <module>SPE</module>
  </modules>
  <commandRestrictions mode="blocklist">
    <blockedCommands>
      <!-- ... -->
    </blockedCommands>
  </commandRestrictions>
</profile>

This creates two layers:

• Module layer -- controls which commands exist in the session
• Command layer -- controls which of those commands are allowed

For read-only-strict, the module list would be even more restrictive -- potentially just SPE and Microsoft.PowerShell.Core.

Additional Commands to Block in All Constrained Profiles

Command	Risk
Import-Module / ipmo	Loads arbitrary modules
Remove-Module	Could remove SPE's own module to break restrictions
Get-Module -ListAvailable	Reconnaissance -- reveals what is installed on the server
New-Module	Creates dynamic in-memory modules
Invoke-Expression / iex	Arbitrary code execution
Invoke-Command	Could target remote runspaces that are not constrained
Start-Job / Start-ThreadJob	Background execution might escape the constrained session
Register-EngineEvent	Event-based code execution
New-PSSession / Enter-PSSession	Remote sessions that bypass local restrictions

Note: The content-editor profile uses allowlist mode, so these are implicitly blocked -- commands not on the allowlist are denied by default.

Updated Profile Example

<profile name="read-only" languageMode="ConstrainedLanguage"
         auditLevel="Violations">
  <modules autoload="None">
    <module>Microsoft.PowerShell.Core</module>
    <module>Microsoft.PowerShell.Utility</module>
    <module>SPE</module>
  </modules>
  <commandRestrictions mode="blocklist">
    <blockedCommands>
      <!-- Module loading -->
      <command>Import-Module</command>
      <command>Remove-Module</command>
      <command>New-Module</command>
      <!-- Execution escape -->
      <command>Invoke-Expression</command>
      <command>Invoke-Command</command>
      <command>Start-Job</command>
      <command>Start-ThreadJob</command>
      <command>Register-EngineEvent</command>
      <!-- Remote sessions -->
      <command>New-PSSession</command>
      <command>Enter-PSSession</command>
      <!-- Write operations -->
      <command>Set-Item</command>
      <command>Remove-Item</command>
      <command>New-Item</command>
      <command>Move-Item</command>
      <command>Copy-Item</command>
      <command>Rename-Item</command>
      <command>Publish-Item</command>
      <command>Protect-Item</command>
      <command>Unprotect-Item</command>
      <command>Install-Package</command>
      <command>New-Package</command>
      <command>Set-Layout</command>
      <command>Add-Rendering</command>
      <command>Remove-Rendering</command>
    </blockedCommands>
  </commandRestrictions>
</profile>

[michaellwest]

Update: Enterprise Architecture Review Findings

Three actionable items from an architectural review of the proposal.

---

1. Scriptblock Parameter Language Mode Enforcement

Gap identified: Trusted scripts that accept scriptblock parameters create a privilege escalation vector. If a trusted function (running in FullLanguage) executes a scriptblock passed by an untrusted caller, that scriptblock runs in FullLanguage -- bypassing the caller's constraints.

# DialogBuilder is Trusted, runs in FullLanguage
Import-Function "DialogBuilder"
New-DialogBuilder -OnSubmit {
    # This scriptblock was authored by the untrusted caller
    # but executes inside the trusted function's FullLanguage scope
    [System.Reflection.Assembly]::LoadFile("C:\evil.dll")
}

Rule: Scriptblock parameters passed to trusted functions must execute in the caller's language mode, not the function's. This matches PowerShell's own CLM behavior with modules -- a FullLanguage module function receiving a scriptblock from a ConstrainedLanguage caller runs that scriptblock in ConstrainedLanguage.

Implementation: When a trusted script executes a scriptblock received as a parameter, the engine must tag the scriptblock with the originating session's language mode and enforce it at invocation time. The export manifest controls which functions get elevated; scriptblock arguments to those functions do not.

Phase: Phase 1 -- this is a security boundary, not a nice-to-have.

---

2. Standard Field Tiering for content-editor Profile

Problem: Blanket blocking of all __ prefixed fields is too blunt. Fields like __Display name, __Sortorder, and workflow fields are common business operations in content management scenarios.

Solution: Categorize standard fields into tiers with sensible defaults:

Tier	Fields	Default
Safe	__Display name, __Sortorder, __Hidden	Allowed
Workflow	__Workflow state, __Default workflow	Allowed
Dangerous	__Security, __Owner, __Renderings, __Final Renderings, __Lock	Blocked
System	__Created, __Created by, __Updated, __Updated by, __Revision	Blocked (Sitecore-managed)

Configuration via standard Sitecore config patching:

<profile name="content-editor" languageMode="ConstrainedLanguage">
  <standardFieldRestrictions>
    <tier name="safe" default="allow">
      <field>__Display name</field>
      <field>__Sortorder</field>
      <field>__Hidden</field>
    </tier>
    <tier name="workflow" default="allow">
      <field>__Workflow state</field>
      <field>__Default workflow</field>
    </tier>
    <tier name="dangerous" default="block">
      <field>__Security</field>
      <field>__Owner</field>
      <field>__Renderings</field>
      <field>__Final Renderings</field>
      <field>__Lock</field>
    </tier>
    <tier name="system" default="block">
      <field>__Created</field>
      <field>__Created by</field>
      <field>__Updated</field>
      <field>__Updated by</field>
      <field>__Revision</field>
    </tier>
  </standardFieldRestrictions>
</profile>

Admins customize by patching individual fields or changing tier defaults. This is more granular than a blanket __ rule while still shipping secure defaults.

Phase: Phase 1.

---

3. Audit-Only Enforcement Mode

Motivation: Teams deploying CLM profiles for the first time need a way to observe what would be blocked before actually blocking it. Without this, adoption requires a leap of faith that risks breaking production integrations.

Solution: Add an enforcement attribute to profiles:

Mode	Behavior
audit	Log violations but allow execution to continue
enforce	Log violations and block execution (default)

<profile name="read-only" languageMode="ConstrainedLanguage"
         auditLevel="Violations"
         enforcement="audit">
  <!-- All restrictions are evaluated but not enforced -->
  <!-- Violations are logged for review -->
</profile>

Workflow:

1. Deploy profile with enforcement="audit"
2. Route remoting traffic through the profiled service
3. Review logs for [AUDIT] entries showing what would be blocked
4. Fix scripts or adjust profile restrictions as needed
5. Switch to enforcement="enforce" when confident

Log format in audit mode:

SPE.Security [AUDIT] User=sitecore\api-user Service=remoting Profile=read-only
  WouldBlock=Remove-Item Script=/path/to/script.ps1
  (enforcement=audit, execution allowed)

Phase: Phase 1. This is the single most important feature for adoption. Without it, teams must choose between "fully restricted" and "fully open" with no safe way to test.