Windows Access Control

This document delves into the fundamental principles and mechanisms of access control within the Windows operating system. Understanding how Windows protects resources is crucial for secure system administration and application development.

Understanding Access Control Lists (ACLs)

At the heart of Windows access control lies the Access Control List (ACL). An ACL is an object that contains a list of Access Control Entries (ACEs). Each ACE defines specific permissions granted or denied to a particular Security Identifier (SID). When a process attempts to access a securable object (like a file, registry key, or process), the operating system consults the object's ACL.

Essentially, an ACL answers the question: "Who can do what with this resource?"

The Structure of an Access Control Entry (ACE)

Each ACE within an ACL has a defined structure, typically comprising the following components:

• ACE Type: Indicates whether the ACE is for access allowed (Allow ACE) or access denied (Deny ACE). Deny ACEs take precedence over Allow ACEs.
• ACE Flags: Control the inheritance of the ACE to child objects.
• Access Mask: A bitmask that specifies the exact permissions being granted or denied (e.g., read, write, execute).
• SID (Security Identifier): The unique identifier for the user, group, or other security principal to whom the permissions apply.

Common Permissions

Windows defines a set of standard permissions that can be applied to objects. These are often grouped into categories:

• Read Permissions: Allow viewing of data and attributes.
• Write Permissions: Allow modification of data and attributes.
• Execute Permissions: Allow running of programs or scripts.
• Delete Permissions: Allow removal of the object.
• Change Permissions: Allow modification of the object's ACL.
• Take Ownership: Allow changing the owner of the object.

More granular permissions exist, and specific object types might expose their own unique sets of permissions.

ACL Inheritance

One of the powerful features of Windows ACLs is inheritance. When a new object is created within a container (like a file in a folder), it can inherit ACEs from its parent. This simplifies permission management by allowing administrators to set permissions at a higher level and have them propagate downwards.

Inheritance can be configured in various ways:

• No Inheritance: The new object gets its own ACL, independent of the parent.
• Inherit All: The new object inherits all ACEs from the parent.
• Inherit Specific Permissions: Only certain types of ACEs (e.g., read ACEs) are inherited.

Security Identifiers (SIDs)

Every user, group, and computer account in Windows is assigned a unique Security Identifier (SID). SIDs are immutable and are used by the system to identify security principals. When an ACE references a SID, it's binding specific permissions to that unique identity.

Understanding SIDs is fundamental to comprehending how access is granted or denied. For example, the SID for the built-in Administrator group is well-known.

S-1-5-21-DomainIdentifier-RID
S-1-5-32-544  (Well-known group: Administrators)
S-1-5-18    (Well-known SID: LocalSystem)