Windows 2000 DACL File Access Evaluation

In Microsoft Windows 2000, file access security relies on Discretionary Access Control Lists (DACLs) evaluated by the Security Reference Monitor (SRM). When a thread attempts to open or manipulate a file on an NTFS volume, the operating system compares the caller's security context against the Access Control Entries (ACEs) within the file’s DACL. This article explains the exact sequential algorithm Windows 2000 uses to process these security structures, determine permissions, and decide whether to grant or deny access.

Core Components of the Evaluation

The access check requires three primary data structures:

  • The Access Token: Represents the calling thread or process and contains the user’s Security Identifier (SID), the SIDs of all groups to which the user belongs, and user privileges.
  • The Desired Access Mask: A bitmask submitted by the caller specifying the exact operations requested (such as FILE_READ_DATA, FILE_WRITE_DATA, or DELETE).
  • The Security Descriptor: Attached to the target file, containing the owner SID, the primary group SID, and the DACL. The DACL contains an ordered list of ACEs specifying permissions for specific SIDs.

Preliminary Checks

Before parsing individual entries in the DACL, the SRM performs baseline checks:

  1. Privilege Overrides: If the caller requests access governed by system privileges (such as SeBackupPrivilege or SeRestorePrivilege), and those privileges are enabled in the access token, the operating system grants the corresponding access immediately without consulting the DACL.
  2. DACL Presence and State:
    • NULL DACL: If the security descriptor contains a NULL pointer for the DACL, the object has no protection, and full access is granted to all users.
    • Empty DACL: If the security descriptor contains a pointer to a DACL that contains zero ACEs, access is denied to everyone except the object owner requesting write access to the DACL (WRITE_DAC).

Canonical Ordering of ACEs

To ensure predictable security enforcement, Windows 2000 expects ACEs within a DACL to be stored in "canonical order." When setting permissions using standard administrative tools, Windows sorts the ACEs as follows:

  1. Explicit (non-inherited) Access Denied ACEs
  2. Explicit (non-inherited) Access Allowed ACEs
  3. Inherited Access Denied ACEs
  4. Inherited Access Allowed ACEs

The Access Evaluation Algorithm

Once preliminary checks pass, the SRM steps through the DACL from top to bottom, one ACE at a time, evaluating the entries against the caller's access token and desired access mask:

  1. SID Matching: The SRM checks if the SID in the current ACE matches the user SID or any active group SIDs present in the caller's access token. If no match occurs, the SRM ignores the ACE and moves to the next one.
  2. Access Denied ACE Evaluation: If a matching SID is found in an Access Denied ACE, the SRM checks whether the denied rights intersect with any of the rights in the caller's desired access mask:
    • If any currently requested access bit is explicitly denied by this ACE, the evaluation terminates immediately, and the caller is returned an Access Denied status.
  3. Access Allowed ACE Evaluation: If a matching SID is found in an Access Allowed ACE, the SRM checks which requested rights are granted:
    • Any rights granted by this ACE that match the remaining requested rights are marked as granted.
    • If all requested access rights in the desired access mask are fulfilled, evaluation stops immediately, and the operating system grants access.
  4. End of List (Implicit Deny): If the SRM iterates through the entire DACL and any requested permissions remain ungranted, the evaluation terminates, and access is denied. Windows 2000 operates on a default-deny model, meaning permissions not explicitly granted are automatically withheld.