menu_bookDocumentation

s&box Sandbox Security Model: Assembly Whitelist, Blocked APIs, Reflection Restrictions, and Safe Assembly Caching

calendar_today May 4, 2026 schedule ~2 min read person patrickjr verified 50

s&box Sandbox Security Model: Assembly Access Control and Whitelisted APIs

s&box uses a whitelist-based security model to prevent game code from accessing dangerous APIs. All game assemblies are verified against AccessRules before being loaded.

How It Works

The AccessControl system uses Mono.Cecil to inspect compiled assemblies at the IL level. Every method call, field access, and type reference is checked against a whitelist of allowed patterns. If any disallowed access is found, the assembly is rejected.

Whitelisted Assemblies

Game code can reference these assemblies:


What's Blocked

Notable restrictions in System.Private.CoreLib:


Reflection Restrictions

Game code can read reflection metadata (names, types, attributes) but cannot invoke methods or get/set property values via reflection. Use Game.TypeLibrary instead for safe reflection.

SHA256 Hashing

CSHARP
// This is allowed in game code
using var sha256 = System.Security.Cryptography.SHA256.Create();
var hash = sha256.ComputeHash( data );

HTTP Requests

CSHARP
// HttpClient is NOT directly accessible — use Sandbox.Http or Game.Http instead
// But HttpResponseMessage, HttpContent etc. are accessible for handling responses

Safe Assembly Caching

Once an assembly passes verification, its SHA256 hash is cached. If the same assembly bytes are seen again, the cached result is used without re-verifying.

Was this helpful?