Security

A registry operation can need rights on both the target key and the layer being changed. Start with the operation's error and the exact key; do not assume that administrator membership or access to a parent grants every registry operation.

Inspect the key's permissions #

reg sd Machine/System/KMES

Or open Permissions… on the key in Registry Editor. A key's security descriptor contains its owner, DACL and, optionally, SACL. It protects all values in that key; values do not have separate access controls.

reg sd normally shows owner, group and DACL. Reading or changing a SACL requires the privileged ACCESS_SYSTEM_SECURITY right. If inspection is denied, ask the key's administrator to review the needed operation rather than broaden access to the entire registry.

The registry-specific rights #

The common bundles are KEY_READ (query, enumerate, notify and read the SD), KEY_WRITE (set values and create subkeys) and KEY_ALL_ACCESS. Ordinary reads and writes use AccessCheck against the key; privileges do not grant blanket ordinary registry access. Backup and restore have their own privilege-gated path.

Also check the destination layer #

A layer-targeted write needs KEY_SET_VALUE on that layer's metadata key under Machine\System\Registry\Layers\<LayerName>, as well as the operation's right on the target key. The layer's displayed owner SID is informational; its metadata key's security descriptor controls access.

On a stock system, base-layer authorization falls back to a descriptor that allows Authenticated Users to write into base, while each target key still controls what they may change.

Creating a layer above precedence 0, or raising a layer's precedence above 0, additionally requires SeTcbPrivilege. Ordinary writes into an existing layer use the target-key and layer permissions described above. Deleting a layer requires DELETE on its metadata key. See the layer rights reference.

No traversal check #

Opening a key checks that key's descriptor, not every ancestor's. If you know a path, you can sometimes open it even when you cannot list its parent. Conversely, restricting a parent does not automatically protect every existing key below it. Inspect the keys containing the data you need to protect.

Where a key's SD comes from #

Inheritance is computed when a key is created. Changing a parent's permissions later does not automatically rewrite existing descendants; reapplying inheritance requires a deliberate administrative operation.

The standard root defaults are:

• Machine: SYSTEM and Administrators have full control; Authenticated Users can read. These grants are inheritable.
• Users\<SID>: that user, SYSTEM and Administrators have full control.

A component can set tighter permissions on its own subtree. Verify the actual descriptor instead of relying on the default description.

The handle model #

Rights are granted when a key is opened and retained on that handle. Tightening the descriptor affects future opens; it does not revoke an already-open handle. If an access change must affect a running service, arrange for it to reopen the key through its documented reload or restart.

Watching and reading are separate rights #

KEY_NOTIFY permits watching; KEY_QUERY_VALUE permits reading values. A subtree watcher can learn that a descendant appeared or disappeared without being allowed to read that descendant's contents. It still must open the descendant and pass its access check to read it.

The sharp edge: security is not layered #

Before a security change, save an appropriate backup and inspect the current descriptor. Afterward, check the descriptor and test future opens under the relevant identity. A value that contains a descriptor, such as an SdDefaults override, is a different case: it is layered data, but changing it does not retroactively rewrite objects already stamped from it.

Where to go next #

• Security descriptors and inheritance
• Default descriptors for newly created objects
• Privileged backup and restore
• LCS access flow for the kernel details

An SdDefaults value tells a component which security descriptor to stamp on an object it creates. Changing it affects future stamping; it does not repair the permissions of objects already on disk or in memory.

Find the component's default #

The convention is a named REG_SZ value containing SDDL under:

Machine\Software\<Software>\SdDefaults

The value name identifies the object, such as SpoolDirectory, StateFile or Run. These are examples, not names every component provides. Each component keeps its own names beside its own configuration.

Use regman for the exact key and value before editing it. Read its Applies field: the relevant object may be stamped at startup, on a mount, or only when it is first created. Inspect the current override with reg get or Registry Editor, and record whether it was absent.

Compiled default, registry override #

An invalid descriptor is not repaired or broadened automatically. This fallback does not prove that the policy is the one you intended: inspect the rejection event and verify the actual descriptor on the created object. A syntactically valid descriptor can also grant more access than intended, so validity alone is not a security review.

When a change takes effect #

1. Read the value's manual and understand when its component stamps the object.
2. Save the old value and the relevant recovery state.
3. Make the intended SDDL change with the correct type and destination layer.
4. Let the component create or stamp an object through its documented workflow.
5. Inspect that object's actual permissions and the component's events.

Changing the default does not rewrite existing objects. Children inherit from their parent at creation, so existing descendants are not updated either. Do not delete a live object merely to force restamping without understanding that component's recovery procedure.

Layer removal can remove the override value, but it cannot undo descriptors already stamped onto objects while the override was effective. This is separate from the rule that a registry key's own descriptor is not layered.

The values are access policy — protect them #

Whoever can write these values controls access to objects the component will create. The convention protects the SdDefaults key so only SYSTEM and Administrators can write. Check its actual permissions and the write destination layer.

Do not confuse the key's Permissions… with the descriptor stored as a value: the first governs who may change configuration, while the second is consumed as policy for another object.

What the convention does not cover #

• Bootstrap seeds: descriptors needed before a registry source exists are compiled into the tools that stamp them.
• Kernel fallback templates: fixed fallbacks used when mount policy has no template are not SdDefaults settings. An object created without a parent instead uses the creating token's default DACL; authd obtains that from the principal's DefaultDacl policy value. A token with none leaves such an object with a null DACL. See Assigning privileges.
• Package payload files: these inherit at their destination or use a package-manifest descriptor declaration; see PSPU §5.20.

For component authors #

The convention requires a reviewed compiled default for each object-named value, fallback to that default with a recorded rejection for invalid SDDL, and a regman entry specifying when it is stamped. Do not substitute a broader policy on parse failure.

Where to go next #

• SDDL and security descriptors
• Inheritance
• Make and verify registry changes