GSoC 2026: Idea #8 — Native Windows Sandbox using AppContainer

[AnushkaPandit-21]

Interest & Background

Hi, I'm Anushka Pandit (@AnushkaPandit-21), a final-year CS student at BITS Pilani. I'm interested in working on Idea #8: Native Windows Sandbox using AppContainer for GSoC 2026.

I develop on Windows 11 and have experience with Win32 security APIs, Node-API/node-gyp, and TypeScript.

Working Proof of Concept

I've built a fully functional PoC that demonstrates AppContainer sandboxing through a C++ Node-API addon:

Repository: https://github.com/AnushkaPandit-21/appcontainer-node-sandbox

What's implemented and tested:

AppContainer process isolation:

• CreateAppContainerProfile / DeleteAppContainerProfile for profile lifecycle
• SetNamedSecurityInfo + SetEntriesInAcl for per-path filesystem ACLs
• CreateProcessW with PROC_THREAD_ATTRIBUTE_SECURITY_CAPABILITIES for sandboxed process spawning
• Capability SID management (InternetClient, InternetClientServer, PrivateNetworkClientServer)

WFP network isolation:

• FwpmEngineOpen0 + FwpmFilterAdd0 for block-all outbound filter (weight=1)
• Per-rule allow filters for specific ip:port (weight=15, overrides block)
• Maps directly to the proxied Seatbelt profile pattern

TypeScript integration layer:

• createSandbox() / runInSandbox() / destroySandbox() API matching sandbox.ts expectations
• buildConfig() with open / proxied network profiles mirroring Seatbelt profile selection
• Abort signal support, AppContainerError with Win32 error codes

Test results on Windows 11:

Test A — write to C:\Windows\ (should be BLOCKED)
PASS AppContainer blocked write to C:\Windows\

Test B — write to ACL-granted directory (should SUCCEED)
PASS AppContainer wrote successfully to ACL-granted directory

Seatbelt Parity

I've mapped every macOS Seatbelt restriction to its AppContainer equivalent:

Seatbelt	AppContainer	Status
(deny file-write*)	No ACL on host paths (default)	Done
(allow file-write* (subpath X))	SetNamedSecurityInfo grants write	Done
(allow network-outbound) — open	InternetClient capability SID	Done
(deny network-outbound) + proxy	WFP block-all + allow-list	Done
Registry isolation	Automatic per-instance hive	Built-in
Process isolation (Low IL)	Automatic	Built-in

Integration Points

I've identified three hook points in the codebase:

1. sandboxConfig.ts:getSandboxCommand() — add win32 → 'appcontainer'
2. sandbox.ts:start_sandbox() — add appcontainer dispatch branch
3. VALID_SANDBOX_COMMANDS — add 'appcontainer' to the union type

My Contributions So Far

• PR #20759: test(core): add missing tests for errorClassification
• Issue #20780: feat(sandbox): add Windows platform detection in sandboxConfig.ts
• Technical analysis comment on issue CLI throws ParserError on Windows PowerShell 5.1 due to '&&' operator #20773 (PowerShell 5.1 && bug)

Questions for Mentors

1. Should the AppContainer driver live in a new packages/windows-sandbox/ package or inside packages/cli/?
2. For the WFP network filters, is administrator privilege acceptable or should there be a fallback for non-admin users?
3. I see #20043 (Sandbox Architecture Refactoring) is in progress — should the AppContainer driver target the new architecture, or integrate with the current one first?

I'd appreciate any guidance from @gaurghosh or the sandbox team. Happy to answer questions about the implementation approach.

[AnushkaPandit-21]

Architecture deep-dive

For anyone interested in the technical details, I've documented the full Win32 API call sequence in the PoC README. The key insight is that AppContainer cannot be a shell wrapper like sandbox-exec — it requires a C++ Node-API addon because:

• SECURITY_CAPABILITIES must be attached via PROC_THREAD_ATTRIBUTE_LIST at process creation time
• Filesystem ACLs require SetNamedSecurityInfo with the AppContainer SID
• WFP filter management requires FwpmEngineOpen0 / FwpmFilterAdd0 with native handles

This is fundamentally different from the macOS path where sandbox-exec is a shell command that wraps the target process.