On Windows the log-hash key is held to an allowlist, so a key anyone beyond SYSTEM, Administrators and the service can read is refused (#4028)

[erikdarlingdata]

Closes #4028.

Why

#4020's review (Low 3): on Windows the log-hash key was trusted through the credential check it shares with the role credential files. That check refuses only a file Users, Authenticated Users or Everyone can read, so INTERACTIVE, Domain Users or one named user holding ReadData passed it. Whoever can read the key can test guesses at every literal the keyed hashes hide.

What changes

• New DarlingFileSecurity.AccessBeyondTrusted(path): an allowlist over the trusted-owner set (SYSTEM, Administrators, the service account). It names every other account holding ANY Allow entry, or reports a DACL it can't read.
• DarlingLogHashKeyFile.Load refuses a key with any such reader, after the shared check. Creating a key verifies against the same allowlist, so a key is never written that the next start would refuse.
• The credential files keep the denylist their existing DACLs were built against. darling.json is read by INTERACTIVE by design, so this can't newly refuse an install's credentials.

Round-1 review fixes (cd02713)

• Medium: the check asked only who could READ. An account with WriteData could plant a key of its own. Any local user can make a valid one, because the DPAPI is LocalMachine and the entropy is in the source. An account with ChangePermissions or TakeOwnership could grant itself the read. Now any Allow entry for anyone beyond the three trusted accounts refuses the key, whatever it grants. The service writes only those three entries.

• Low: the key was checked by path, then read by path. Whoever controls a pre-existing darling-keys could swap the file in between. DarlingFileSecurity.OpenForServiceOnlyRead opens the key once, without following a link at its name and sharing read alone, so nobody can rename, delete, replace or write it while it is held. Through that handle it checks:

  • reparse point or directory;
  • hard links (more than one name is refused);
  • the owner;
  • the allowlist.

  The read then uses the same handle, bounded to 1 KB. A key this service writes is about 350 bytes. This closes the swap without the directory allowlist, which stays out of scope below.

• Low: the Unix half of Log-hash key trust: check who owns the key directory and file on Unix, and allowlist the directory's DACL on Windows (#4020 review, Low) #4028. This stays out of scope by the ruling; see below. The reviewer's FIFO point is the same case.

Not done, and closed with this

• Unix owner checks and the FIFO case (Log-hash key trust: check who owns the key directory and file on Unix, and allowlist the directory's DACL on Windows (#4020 review, Low) #4028 part 1): the container runs as root, so ownership adds little, and The log-hash key's directory is judged by the mode the start found it with, so a key planted while it was open is discarded (#4004) #4031 already discards anything planted in an open credential directory. Skipped per the recommendation on Log-hash key trust: check who owns the key directory and file on Unix, and allowlist the directory's DACL on Windows (#4020 review, Low) #4028.
• Windows directory DACL allowlist (Log-hash key trust: check who owns the key directory and file on Unix, and allowlist the directory's DACL on Windows (#4020 review, Low) #4028 part 2): a user who pre-creates the key's directory can delete the key (forced rotation, a DoS) but can't read it, since the key file is created with its own protected DACL. The install folder itself is locked by Install and upgrade lock the Darling install folder, so an ordinary local user can no longer replace the service's binaries (#4034) #4038. Skipped per the same recommendation.

Test plan

• New AKeyAnyoneBeyondTheServiceCanRead_IsRefused_OnWindows. A real key, with an INTERACTIVE read grant added, is refused with INTERACTIVE named; the file is untouched; and the shared denylist alone would have loaded it.
• Red-watch: without the load check, the test fails.
• Review fixes, each red-watched by reverting it:
  • AKeyAnyoneBeyondTheServiceHoldsAnyRightTo_IsRefused_OnWindows: WriteData, AppendData, ChangePermissions, TakeOwnership and Delete. All 5 fail with the ReadData-only filter restored.
  • AHeldKey_CannotBeRenamedDeletedOrWritten_UntilItIsReleased_OnWindows: fails when the handle shares write and delete.
  • AHardLinkedKey_IsRefused_OnWindows: fails without the link-count check.
  • AnOversizedKey_IsRefused_OnWindows: fails without the 1 KB bound.
• After merging dev, all green, 0 warnings: PgLogHashKey* 26, DarlingFileSecurity* 17, *HardenFiles* 19, DocCommentHygiene 77, DarlingManagedRoles* 27.
• PgLogHashKey*, DarlingFileSecurityTests, DarlingHardenFilesVerbTests, DarlingStoreLoginsTests, ComposeStoreRolesLiveTests: 114 green, plus the new test. Build: 0 warnings.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GdmA4ND1wLSqA91ax1m4xv