Security Reference Monitor in Windows 2000

The Security Reference Monitor (SRM) is the core kernel-mode engine responsible for enforcing object access control and generating audit messages in Microsoft Windows 2000. Operating within the Windows Executive, the SRM acts as the primary gatekeeper for the operating system, ensuring that any attempt by a user, thread, or process to access a secured resource is verified against defined permissions. By comparing a user's access token directly to an object's security settings, the SRM guarantees that security policies are uniformly applied across all system objects.

Core Responsibilities of the SRM

In Windows 2000, the SRM handles three fundamental tasks:

  1. Access Validation: It determines whether a subject (a thread acting on behalf of a user) has the required permissions to open or interact with a securable object.
  2. Privilege Checking: It verifies whether a user account holds the specific user rights or privileges necessary to perform restricted system-wide actions, such as shutting down the system or taking ownership of a file.
  3. Audit Logging: It checks the System Access Control List (SACL) of an object to determine whether an access attempt (successful or failed) must be audited and logged to the Security event log.

How the SRM Checks Access Rights

When an application or thread requests access to an object—such as a file, registry key, process, or semaphore—the request goes through the Windows Object Manager, which then invokes the SRM. The validation process proceeds through specific evaluation steps:

1. Comparing Access Tokens and Security Descriptors

Every active thread possesses an Access Token (inherited from the user’s logon session or a specific impersonation token). This token contains:

  • The user's Security Identifier (SID).
  • The SIDs of all groups the user belongs to.
  • Granted privileges.

Every securable object possesses a Security Descriptor, which contains:

  • The Owner SID.
  • A Discretionary Access Control List (DACL) defining who is granted or denied access.
  • A System Access Control List (SACL) defining auditing rules.

The SRM reads the requested access mask (the exact permissions the thread wants, such as Read, Write, or Delete) and compares the thread's SIDs against the Access Control Entries (ACEs) inside the object's DACL.

2. DACL Evaluation Logic

The SRM reads the DACL sequentially from top to bottom:

  • Explicit Denials First: If the SRM encounters an "Access Denied" ACE matching the thread’s SID or group SIDs, access is immediately refused, regardless of any subsequent allow permissions.
  • Accumulating Permissions: If the SRM encounters an "Access Allowed" ACE, it marks those specific rights as granted. The SRM continues scanning until all requested rights in the desired access mask are fulfilled.
  • Implicit Deny: If the SRM reaches the end of the DACL and any of the requested access rights remain ungranted, access is denied. If an object has no DACL (a null DACL), access is granted to everyone; if it has an empty DACL, all access is denied.

Auditing and LSASS Communication

In addition to granting or denying access, the SRM evaluates the object's SACL. If the SACL specifies that the attempted operation must be audited, the SRM constructs an audit record. Because the SRM runs in kernel mode, it cannot write directly to the event log file. Instead, it sends the audit message across a secure Local Procedure Call (LPC) to the user-mode Local Security Authority Subsystem Service (LSASS), which writes the event to the Windows 2000 Security Log.