design(windows): add explicit strict application allowlist mode for restricted classroom users

[balejosg]

Summary

Add an explicit opt-in strict application-control mode for Windows classrooms that require the stronger guarantee:

restricted student may execute only explicitly approved application surfaces
unknown executable/browser -> denied by default

This is deliberately separate from the default compatibility policy in #254.

The default managed-browser policy must continue to support legitimate centrally installed classroom applications without requiring an exhaustive application catalog. That compatibility requirement makes it impossible to also guarantee that an arbitrary previously unknown browser placed by an administrator under Program Files will be denied: AppLocker cannot infer "this executable is a browser" generically.

Strict mode resolves that contradiction by changing the contract explicitly rather than silently tightening the default.

Related:

• P1 windows: installer can leave AppLocker and watchdog absent while AppControl is configured Enforced #253 — reliable AppControl lifecycle/effective enforcement.
• P1 windows health: endpoint can appear healthy while AppControl/watchdog boundary is absent #186 — truthful AppControl/watchdog health.
• security(windows): harden unapproved-browser discovery and portable-executable AppLocker rules #254 — harden default compatibility mode: discovered unapproved browsers + portable execution.
• release(windows): promote post-#246/#253 fixes with physical installer evidence before claiming them delivered #255 — promoted/shipped Windows artifact evidence.

This issue does not block #253/#255 unless the release decision explicitly requires strict mode to ship atomically.

---

Product contract

Introduce two intentionally different policy profiles (names may follow repository conventions):

ManagedBrowserCompatibility   # existing/default behavior hardened by #254
StrictApplicationAllowlist    # this issue

Compatibility profile

approved browser(s) allowed
supported/discovered unapproved browsers denied
portable/user-controlled execution denied
centrally installed classroom applications remain compatible

Strict profile

approved browser(s) allowed
explicitly approved classroom applications allowed
required Windows/OpenPath runtime allowed
all other restricted-user executable/script surfaces denied by default

The configuration/state must make the active profile unambiguous. Do not infer strict mode merely from the presence of an app list.

---

Design requirements

1. Explicit approved-application catalog

Strict mode needs a durable operator-managed application approval contract.

Prefer stable identities in this order where practical:

publisher/product/binary constraints for properly signed applications
safe path rule only when the location is admin-controlled and cannot be written by restricted users
hash for unsigned/pinned binaries when no safer stable identity exists

Do not use a broad path Allow over a location writable by standard users.

Do not require hashes for routinely updated signed software when a sufficiently constrained publisher rule can express the intended trust.

Define schema/versioning and validation for application approvals. Reject ambiguous/unsafe entries instead of silently widening policy.

2. Approved browsers remain a first-class subset

approvedStudentBrowsers remains authoritative for browsers.

Strict mode must not require operators to duplicate the approved browser in a generic app list. Generate the required verified browser application surface from the canonical browser discovery/release contract.

Firefox Release approval must not accidentally approve Tor Browser or Firefox Portable.

3. Windows/OpenPath baseline must be minimal and explicit

Inventory every OS/OpenPath executable/script surface the restricted student legitimately needs.

Do not preserve %PROGRAMFILES%\* merely for convenience: that would defeat strict mode.

Use the smallest maintainable combination of:

Windows system path/publisher rules
OpenPath-owned runtime paths
Microsoft packaged-app rules where product-required
specific approved application rules

Document every broad baseline rule and why it cannot be abused to execute arbitrary third-party code.

4. Unknown installed executable must be denied

This is the differentiating strict-mode invariant.

Prepare a benign synthetic executable as administrator in a managed install location, for example:

C:\Program Files\FutureBrowser\future.exe

Do not add a FutureBrowser deny rule.

For the restricted student in strict mode:

Test-AppLockerPolicy / real execution -> denied by default

The same test is intentionally not a requirement of compatibility mode #254.

5. Legitimate classroom apps require explicit approval

Use at least one representative signed classroom application fixture/real app in E2E:

not approved -> denied
approved -> allowed

Prove an application update behaves according to the selected identity type:

• publisher rule: compatible update remains allowed;
• hash rule: changed binary becomes denied until approval updates.

6. Policy transition must be transactional

Switching from compatibility to strict mode can make applications stop launching.

Required transition:

validate strict config/catalog
build candidate AppLocker policy
preflight required Windows/OpenPath/admin recovery surfaces
apply
validate effective/runtime decisions
commit active profile

If candidate validation fails, restore/retain the previous known-good boundary and report the transition failure.

Do not persist StrictApplicationAllowlist as active before effective validation succeeds.

Switching back to compatibility mode must likewise remove strict-mode managed rules deterministically without deleting unrelated administrator-managed AppLocker rules.

7. Health/readiness includes profile identity

When strict mode is configured, health must verify the effective policy corresponding to strict mode, not merely "some AppLocker policy exists".

Stable diagnostics should distinguish at least:

strict-catalog-invalid
strict-required-rule-missing
strict-effective-policy-mismatch
strict-runtime-probe-failed
strict-transition-failed

Integrate with #186 rather than creating a second health subsystem.

8. Recovery remains possible

Administrators/SYSTEM must retain a tested recovery path even when the strict student policy is malformed.

Do not scope student denies to administrators accidentally.

---

Implementation order for an LLM agent

Phase 0 — design inventory before code

1. Read root AGENTS.md and windows/AGENTS.md completely.
2. Read P1 windows: installer can leave AppLocker and watchdog absent while AppControl is configured Enforced #253, P1 windows health: endpoint can appear healthy while AppControl/watchdog boundary is absent #186, and the final security(windows): harden unapproved-browser discovery and portable-executable AppLocker rules #254 implementation.
3. Read windows/lib/AppControl.psm1 and AppLocker tests completely.
4. Inventory executable/script surfaces currently allowed by the compatibility policy.
5. Classify each required strict-mode surface as:
   • OS baseline;
   • OpenPath baseline;
   • approved browser;
   • operator-approved application;
   • unnecessary in strict mode.
6. Propose the strict approval schema and rule-condition strategy before editing runtime code.

Do not implement strict mode by simply deleting %PROGRAMFILES% allows and then chasing failures one executable at a time.

Phase 1 — schema/config tests

TDD:

explicit compatibility profile -> valid
explicit strict profile + valid catalog -> valid
strict + unsafe writable Allow path -> reject
strict + malformed publisher/hash entry -> reject
profile absent -> preserves documented default compatibility behavior

Phase 2 — policy generation tests

Prove strict policy:

has no generic restricted-user Program Files allow
allows required OS/OpenPath baseline
allows approved Firefox Release
allows explicitly approved test application
does not contain FutureBrowser-specific deny
FutureBrowser remains unmatched by Allow -> denied by default

Phase 3 — transactional transition tests

Inject failures at:

catalog validation
policy apply
effective-policy validation
runtime probe
commit-state persistence

Assert previous known-good profile/policy remains recoverable and active state is truthful.

Phase 4 — real Windows E2E

Under the same standard local student context prove:

Firefox approved -> allowed
Edge unapproved -> denied
portable PE -> denied
FutureBrowser synthetic Program Files PE -> denied without brand-specific rule
approved classroom app -> allowed
same app not approved -> denied
required Windows shell/session functionality -> works
OpenPath runtime/watchdog -> works
administrator recovery -> works

Then switch back to compatibility profile and prove managed classroom application compatibility returns without leaving stale strict managed rules.

---

Acceptance criteria

• Strict mode is explicit and opt-in; default compatibility behavior does not silently change.
• Strict mode has a validated/versioned approved-application catalog.
• Approved browsers are derived from the canonical browser contract and need no duplicate generic app entry.
• Restricted-user strict policy has no blanket arbitrary third-party Program Files execution allowance.
• Synthetic unknown FutureBrowser executable under Program Files is denied by default with no brand-specific deny rule.
• Explicitly approved representative classroom application is allowed.
• Same unapproved application is denied.
• Unsafely writable path approvals are rejected.
• Required Windows/OpenPath functionality remains usable.
• Admin/SYSTEM recovery remains usable.
• Compatibility -> strict transition is transactional and effectively validated before commit.
• Failed transition does not persist a false strict-active state.
• Strict -> compatibility transition removes only OpenPath-managed strict rules.
• P1 windows health: endpoint can appear healthy while AppControl/watchdog boundary is absent #186 health reports the configured/effective profile truthfully.
• Focused Pester and real Windows E2E pass.

---

Non-goals

• Do not make strict mode the default as an incidental refactor.
• Do not duplicate AppLocker lifecycle/health logic from P1 windows: installer can leave AppLocker and watchdog absent while AppControl is configured Enforced #253/P1 windows health: endpoint can appear healthy while AppControl/watchdog boundary is absent #186.
• Do not classify applications based only on filenames.
• Do not create ClassroomPath-specific policy concepts in OpenPath.
• Do not deploy/release/tag without separate authorization.

Completion report

Report:

1. profile/config schema;
2. approved-application identity model;
3. strict Windows/OpenPath baseline inventory;
4. managed rules added/removed compared with compatibility mode;
5. transactional transition design;
6. unknown FutureBrowser result;
7. approved/unapproved classroom app results;
8. admin recovery evidence;
9. focused tests and real Windows results;
10. operational migration guidance for deployments opting into strict mode.

Final invariant:

StrictApplicationAllowlist means unknown code is denied because it is not approved,
not because OpenPath happened to know its brand name.

[balejosg]

2026-09-08 implementer clarification — strict mode must cover all execution collections that can undermine the contract

The strict profile promises more than an EXE-path cleanup. Implementers must audit every AppLocker collection / launch surface that can execute code for the restricted student.

1. Do not define strict mode only in terms of Exe

At minimum decide and test policy for:

Exe
Script
Msi
Appx
Dll (explicitly enabled or explicitly documented out-of-scope with rationale)

Examples of failure modes if left implicit:

• msiexec.exe is allowed from Windows and an MSI collection remains NotConfigured;
• broad Microsoft-signed Appx Allow lets unapproved packaged applications run even though strict mode claims "only explicitly approved application surfaces";
• script hosts / script collection behavior allows code paths that bypass the intended executable catalog.

The final strict-mode contract must state which collections are enforced and why.

2. Publisher approvals need bounded semantics

For signed software, do not approve Publisher=* / Product=* / Binary=* unless that whole publisher really is trusted for the student boundary.

Prefer the narrowest stable condition that survives legitimate updates:

publisher + product + binary
+ version range policy chosen deliberately

Tests should prove that a sibling product signed by the same publisher is not accidentally allowed when only one classroom application was approved.

3. Appx packaged apps are first-class in strict mode

The compatibility profile can preserve broad Microsoft packaged-app behavior if that is the current product contract. Strict mode cannot silently inherit that if it contradicts the allowlist promise.

Inventory the Microsoft/Store packaged apps actually required for the student session and allow only the required product/publisher surfaces. Explicitly test Edge/Appx browser behavior where relevant.

4. MSI approval is not equivalent to installed-app approval

If MSI execution is allowed in strict mode, define whether that means:

approved installer may run

or

approved application may run after installation

These are separate permissions. Do not let an approved installer path become a generic way to introduce arbitrary executable content that then inherits a broad path Allow.

5. Transition preflight must be side-effect free

Before committing compatibility -> strict, generate/evaluate the candidate policy without mutating the current known-good policy where possible. Runtime validation after apply is still required, but the preflight should catch schema/rule-generation errors before crossing the mutation boundary.

Persist profile state only after:

candidate generated
policy applied
effective collections verified
representative runtime probes pass

6. Recovery surface must not weaken student policy

Admin/SYSTEM recovery should come from admin/SYSTEM-scoped rules and a tested elevated recovery path, not from broad Everyone allowances that also help the restricted student.

Additional E2E matrix

Add at least these strict-profile probes on real Windows:

unknown EXE under Program Files -> denied
unapproved MSI -> denied or documented decision
unapproved script -> denied
unapproved packaged app -> denied
approved browser -> allowed
approved signed classroom app -> allowed
sibling same-publisher unapproved app -> denied
admin recovery -> allowed

If DLL enforcement is intentionally not enabled, document the residual risk and why it does not invalidate the advertised strict-mode contract.