5.9 Registry Security Fundamentals

The Registry's hierarchical arrangement looks suspiciously like that of a filesystem in more ways than one. Like NTFS files, directories, and volumes, Registry keys can have attached attributes that control who owns them, who may read, write, and change them, and what events should be logged for further scrutiny.

In particular, every key has an access control list, or ACL, associated with it. The ACL is made up of zero or more access control entries, or ACEs. Each ACE grants a specific permission to a specific user or group. The permissions specified by the ACEs in the ACL apply to the object that holds the ACL and its children, if any. There are actually two separate kinds of ACL: a discretionary ACL (DACL) contains the permissions you put on the key, and a system ACL (SACL) contains permissions applied (and managed) directly by the OS.

5.9.1 Basic Registry Permissions

Some Windows 2000 permissions apply to more than one kind of object. However, the semantics of Registry permissions are a bit different from those of filesystem or objects. Table 5.2 shows the 10 basic permissions that can be attached to Registry keys. These permissions are also called Discretionary Access Controls, or DACs.

Table 5.2. Registry Access Permissions

Permission	What It Allows
Query Value	Retrieving a specific key's value: for example, the value Paul Robichaux of the HKLM\SOFTWARE\SMAIL\Users key
Set Value	Changing the contents of a specific key's value
Create Subkey	Creating a new subkey of the specified key; the new subkey inherits the parent's permissions, but they may be explicitly changed later
Enumerate Subkeys	Traversing all subkeys of a specific key and getting their full pathnames
Notify	Receiving or setting auditing notifications
Create Link	Creating a symbolic link (such as a shortcut or a Unix symlink) that points to another key in the Registry
Delete	Removing the specified key, its subkeys, and all associated values
Write DAC	Changing the DACs attached to the specified key
Write Owner	Changing the owner of the specified key. This permission is new in Windows 2000.
Read Control	The permission holder can read the ACL for the key

Besides these basic DACs, there are additional composite DACs. These composites grant combinations of two or more of the rights listed in Table 5.2. For example, the Full Control composite grants all 10 of the rights listed above. Table 5.3 shows the composite DACs and the rights they include.

Table 5.3. Composite DACs

Permission	What It Allows
Read	Read-only access to a specific key, its subkeys, and their values (actually includes Query Value and Enumerate Subkeys)
Write Owner	Changing the owner associated with the specified key; in Windows 2000, this is a basic permission, not a composite
Full Control	All of the above rights; Full Control allows the holder to do literally anything to the keys with that permission

Some older versions of NT exhibit a serious security weakness: by default, many of the keys in the Registry are set to Everyone:Full Control access. This is unnecessarily permissive. See Chapter 9 for more details on how to tighten your Registry permissions for Windows 2000 and NT.

5.9.2 Applying ACLs

Both Windows 2000 and NT use some fairly simple rules to evaluate ACEs and decide whether you get access to a particular resource or not. Understanding these rules and how they work is critical to knowing how to secure your systems.

The first rule is actually a significant difference in how permissions are handled between Windows NT and Windows 2000. In NT, you can explicitly deny someone access by giving them the No Access permission. In Windows 2000, there are separate Allow and Deny flags in each ACE entry. This difference becomes important when you consider it in the light of the ACL evaluation rules:

Everything not specifically permitted is forbidden

Much as in the old Soviet Union, the only access that's permitted is whatever is explicitly granted by the ACEs on the object. For example, if the ACL on a key contains a single ACE that specifies Administrators:Allow Full Control, no one else has any access because there's no explicit grant of access.

The most restrictive permission always wins

If two or more ACEs conflict, the effective permission is always the most restrictive ACE. For example, consider a Registry key that has Authenticated Users: Allow Read and Domain Users: Deny Read. A domain user's effective permission will be Deny Read, since that's the most restrictive ACE that applies to the user.

Taken in combination, these two rules allow you to calculate the effective permission that result from any combination of ACEs in an ACL. They also highlight why Microsoft added separate Allow and Deny flags. Since the most restrictive permission is always used, an explicit denial (using the Deny flag) is always more powerful than any grant of the same right. Rather than depending on the implicit denial rule (#1 above), you can gain improved security (and clearer semantics) by expressly denying access to an object.