From 49734efb355b6316b366ddc48c7abd1937aecab9 Mon Sep 17 00:00:00 2001 From: Raimund Andree Date: Sat, 10 Oct 2026 08:11:07 +0000 Subject: [PATCH] docs(lab): record the findings of the security review The built-in security-review agent (the custom security-reviewer still can't start: its model isn't offered, and it wasn't overridden) read the branch and found no exploitable vulnerability in the module changes. It reported two LOW items that are not changed and are left for the maintainer: the swallowed initialization exceptions of GetEffectiveAccess (older than the fixes and not reproducible on any machine of the matrix) and the ACL of the stage folders under C:\ in the lab kit. The record, the Memory Bank, and the next steps say so, and the record says how the decision of "this computer" was tested. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: AI Assistant --- .memory-bank/activeContext.md | 27 ++++++++++---- .memory-bank/progress.md | 6 ++-- Tests/Lab/Acceptance-2026-10-10-os-matrix.md | 38 +++++++++++++++++++- 3 files changed, 62 insertions(+), 9 deletions(-) diff --git a/.memory-bank/activeContext.md b/.memory-bank/activeContext.md index 3bae459..413fce8 100644 --- a/.memory-bank/activeContext.md +++ b/.memory-bank/activeContext.md @@ -23,7 +23,7 @@ cells of the matrix (1,374 passed, 0 failed, 12 skipped) and in the first lab, where case 9 runs (245 passed, 0 failed, 1 skipped per edition). Handoff 3: Decision 22 was confirmed under the delegation and stays proposed; nothing is published. Handoff 4: Decision 23 (the #34 dossier); the risk acceptance is the maintainer's. The -agent's decisions of the night are D1 to D42 in +agent's decisions of the night are D1 to D46 in `decisions-night-2026-10-09.md` of the session files. Stable 5.0.0 stays gated. The earlier state of handoff 1, from the reviewed head `f11ff41` of #117: 28 @@ -138,10 +138,15 @@ open. unavailable): approve with Minor, fixed; a second review found one Major (record accuracy), addressed by the replay; a follow-up review found no Blocker or Major and five Minors, corrected; a second follow-up review found no - Blocker or Major and four Minors, corrected. State of the labs at 07:30 UTC on - 2026-10-10: no fixture and no probe residue in either lab (`Verify` of the - matrix lab 06:54, of the first lab 07:29); the six VMs of the matrix run, and - `OSWin11E` (started 06:44) shuts itself down about an hour after its start. + Blocker or Major and four Minors, corrected. The built-in `security-review` + agent (the custom reviewer is still unavailable) found no exploitable + vulnerability in the module changes and two LOW items that are not changed + (Next step 6). A dry run of `Run-MatrixSequence.ps1 -Version 5.0.0-rc6` on + OSFile19 showed that the published-package path works. State of the labs at + 07:50 UTC on 2026-10-10: no fixture and no probe residue in either lab + (`Verify` of the matrix lab 07:45, of the first lab 07:29); the six VMs of the + matrix run, and `OSWin11E` (restarted 07:36) shuts itself down about an hour + after its start. ## Next step @@ -167,4 +172,14 @@ open. the reporters (checklist: `Tests/Lab/Non-Windows-File-Server-Test.md`) and accepting the untested risk with a release-note caveat. No agent can accept it. -6. Do not release stable 5.0.0 or equate a percentage with gate closure. +6. He decides the two LOW findings of the security review (record, Limits): + the swallowed initialization errors of `GetEffectiveAccess` (a false "no + access" instead of an error on an OS that refuses at initialization, and + neither warning nor error when the local fallback fails; fix: record the + initialization exceptions in `authzException`, with a regression test and a + check of the sentence "the error stays" in the help and CHANGELOG), and the + ACL of the stage folders under `C:\` in the lab kit (they inherit + Authenticated Users: Modify; protecting them is a design change of the + controller and needs a new acceptance). The help could also say that a local + standard user who asks about a domain account still gets "Access is denied". +7. Do not release stable 5.0.0 or equate a percentage with gate closure. diff --git a/.memory-bank/progress.md b/.memory-bank/progress.md index 1fc4db9..0413ba5 100644 --- a/.memory-bank/progress.md +++ b/.memory-bank/progress.md @@ -83,7 +83,7 @@ After 5.0.0, archive in favor of WindowsAccessControl (Decision 18). 148 green on the candidate; fixture removed and verified clean on six machines. Record: `Tests/Lab/Acceptance-2026-10-09-quality-gate-paths.md`. - 2026-10-09 to 10: handoffs 2 to 4 under the maintainer's delegation (decisions - D1 to D42 in the night log of the session files). The matrix lab + D1 to D46 in the night log of the session files). The matrix lab `NtfsSecurityOsMatrixLab` (Server 2019, 2022, and 2025 file servers, Windows 11 Enterprise 22H2 client, Windows 11 26H1 suite only) found three defects of the module, fixed in `962887a` and `fdd7a8b`: audit inheritance by descriptor, @@ -105,7 +105,9 @@ After 5.0.0, archive in favor of WindowsAccessControl (Decision 18). `9344ff7`, and `ab0d8e1`; a follow-up review of those fixes found no Blocker or Major and five Minors, corrected in `e2384e5` and `70f494a`; a second follow-up review (the first-lab run and the cleanup changes) found no Blocker or - Major and four Minors, corrected in `b78784d` and `dbb4bd6`. Record: + Major and four Minors, corrected in `b78784d` and `dbb4bd6`; the built-in + `security-review` agent found no exploitable vulnerability and two LOW items + that are not changed (record, Limits). Record: `Tests/Lab/Acceptance-2026-10-10-os-matrix.md`; nothing was pushed. ## Stable capabilities diff --git a/Tests/Lab/Acceptance-2026-10-10-os-matrix.md b/Tests/Lab/Acceptance-2026-10-10-os-matrix.md index a5403b1..4ccc366 100644 --- a/Tests/Lab/Acceptance-2026-10-10-os-matrix.md +++ b/Tests/Lab/Acceptance-2026-10-10-os-matrix.md @@ -646,7 +646,43 @@ fails, which the reuse of the name explains and the module doesn't. throws (an outer `catch { }` that is older than this work). An operating system that refused another computer at that step, not at the context as every machine of the matrix did, would give a result without rights and a warning - instead of the documented error. This is unverified and outside the fixes. + instead of the documented error; and a failure of the local fallback for a name + of this computer would give a result without rights and neither a warning nor an + error, because the flag that suppresses the warning is set before the fallback + runs (also older than this work). The help and the CHANGELOG say that the error + stays for another computer, which holds for the denial at the creation of the + context. This is unverified on every machine of the matrix and outside the + fixes (Decision 16 asks for reproducible defects only); recording the + initialization exceptions in `authzException` would close it. +- The built-in `security-review` agent (the custom `security-reviewer` couldn't + start: its model isn't offered, and I didn't override it) read `83149ee..664ef3a` + and found no exploitable vulnerability in the changes of the module: the + decision "this name is this computer" is an exact, case-insensitive match + (true for `.`, `localhost`, the machine name, the host name, and the name with + the DNS domain; false for null, empty, whitespace, a trailing dot, an IP + address, UNC forms, an embedded NUL, and a name of 100,000 characters, all of + which keep the remote path and its denial), the fallback runs in the caller's + own process and token, and the separate audit read uses the privilege handling + of the combined read. It reported two LOW items. The first is the item above. + The second is that the kit creates staging folders directly under `C:\` + (`C:\NTFSSecurityLab`, `C:\NtfsMatrixLocal`, `C:\NtfsMatrixProbe`, + `C:\NtfsProbeModules`) without an ACL, so they inherit Authenticated Users: + Modify, while scripts and the module's DLL in them run elevated or as the role + accounts: a principal that can run code on a lab VM during a run could replace + them. The labs are isolated and the role accounts must read the tests and write + results there, so protecting the folders is a design change of the controller + that needs a new acceptance; I left it for the maintainer. The reviewer also + noted that the lab password crosses remoting and `Register-ScheduledTask + -Password` (module or script-block logging on a machine would record it), that + the controller reaches the client with CredSSP to an IP address, where the + logon inside CredSSP is NTLM-only and the server isn't authenticated (the + policy comes from AutomatedLab), and that the help says that a user who isn't an + administrator gets the result on a domain computer without saying that a local + standard user who asks about a domain account still gets "Access is denied" (the + probe table above) or that the answer now comes from the caller's own token and + manager. It could not check the ACL of `C:\` on the lab VMs, the behavior of the + fallback as a non-administrator on a domain computer, or whether the local + manager equals the remote one for every token. - The scripts of the kit were read by a reviewer who ran none of them; module logging or script-block logging on a machine would record the lab password that `Register-ScheduledTask -Password` needs.