Table of Contents
- Introduction to the Reference Guide
- The New Itinerary for Windows Server 2008
- The Registry
- Domain Organization
- Executing the Migration Plan
- Resource Management
- Anatomy of a Global Exploit
- Castle Defense: Strategy or Mythology?
- The Mindset Shift in Windows Vista
- Utilizing Local Groups in Vista
- Building Policies with Vista's SIDs
- The New Windows Vista Firewall
- The Vista Alternative: Firewalling as Policy
- Making Vista Play By the Rules
- The Group Policy Effect on Firewalls
- The Keys to Kerberos Authentication
- The Kerberos Cipher: A Thriller in Several Parts
- Conversation with a Three-Headed Dog
- How Modern Authentication Changes Network Architecture
- What Is, and Is Not, Exchanged During Logon
- The Authenticator Is Revealed
- Windows Firewall and the Modern Enterprise Network
- How Group Policy Enables Remote Firewall Control
- Process Authentication
- Digital Certification
- Implementing Transport Layer Security
- Know Who Is Connected Using Two-Factor Authentication
- Clustering in the Virtualization Era
- The Basics of Windows Server Clustering
- When Windows Clustering Started Making Sense
- Overcoming Clustering’s Single Point of Vulnerability
- What Do You Have To Lose?
- Disasters Never Happen To Me
- Logistical Disaster Avoidance
- The Purpose of Access Control Lists
- Making Windows XP "Access Controllable"
- The Authorization Store
- Windows Server Super Security Policy Construction Kit
- Security Policy Construction Kit Continued: Granular Changes to the Security Configuration Template
- Security Policy Construction Kit Continued: Balancing Auditing with Performance
- Securing the File System
- Keeping Files Confidential with EFS
- Security Documentation
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- Networking at the Link Level
- Network Applications
- Windows Management Instrumentation
- The Dawn of Windows Server 2008
- Windows Server By Command
The Purpose of Access Control Lists
Last updated Sep 26, 2003.
In all current editions of Windows, there is now a common model for system security. In this case, "security" is defined as the operating system's ability to restrict access to any file or resource, by a specified user or by a group of users.
Commonly, the security process is characterized as restricting certain people from venturing into territory where they don't belong. In practice, securing Windows Server 2003 is a matter of preventing entities from doing things they shouldn't. System failures are more often the fault of ill-behaved software than any intentionally perpetrated threat. And anyone smart enough to launch a threat these days disguises himself not as a user, but as a logical entityan innocent fragment of code making a seemingly innocuous remote procedure call.
Who Goes There?
In the modern Windows model, users are not necessarily people. Since the most important files used by the operating system should be the most shielded from public use and abuse anyway, the focus of true system security shifts from maintaining this public visibility shield, but marshaling how software components make use of these critical system files. Because Windows enables some software components to communicate with other software components, it invokes a communications protocol specified by the Component Object Model (COM), stating how contact is initiated between the client and server components, and how the client's request for data is satisfied or responded to. But COM is not, by design, secure; in other words, the process by which a server component decides to trust a client component is not stated by COM, but instead left to other Windows services to try to straighten out. Trust requires authentication; and in Windows, the authentication process was originally designed to verify the identities of people, not other processes.
So within Active Directory, the security identifiers (SIDs) (they provide the official "license plate" for active agents within the system) record the presence of processes in a similar way as they do human beings. Both machines and human users have SIDs; and since both types of entities can be clustered into groups within AD, a group of people and a group of resources (for instance, the print servers on the third floor) are identified and authenticated using very similar techniques. Now you can begin to see why malicious users masquerade themselves as system resources.
In today's Active Directory, every identifiable object is defined not by what it is allowed to use and what it is not allowed to use, but instead by to-whom or to-what it permits itself to be used. For security identifiers that represent specific human users, this doesn't really make much sense (although if such a practice were enacted in the real world, the entire process of dating could be radically simplified); however, for files and other Windows resources, this actually simplifies things quite a bit. Every usable resource carries its own "rap sheet"a running tally of who's naughty and who's nicecalled an Access Control List (ACL). Long-time Windows sysadmins refer to these as "ack'·els," if only to lay claim to as many geeky acronyms as Microsoft can make available.
An ACL, one way or the other, accounts for every possible user of its associated file or resource. Since "Everyone" is actually a specified group of users (namely, S-1-1-0), the simplest foreseeable ACL is one which permits full access to everyone. And since the simplest method is usually the default, it becomes the case in Windows that, by default, a new and previously undefined object truly is open to everyone unless otherwise intentionally specified.
It therefore becomes the job (perhaps "the" job) of the WS2K3 administrator to delegate what are called permissions to the various objects in the system. For ordinary files and resources, these permissions are basically grants and denials of access. The best way of imagining the process of delegating permissions is by conjuring the old set logic to which you were probably introduced through high school algebra. Start with "Everyone," or "the set of all things." By default, you know they get access. With as broad strokes as possible, you then deny access to sweeping, extensive groupsentities which would fulfill the phrase, "Everyone except..." Oftentimes, you'll find yourself denying access to Everyone after all. Then, if necessary, you make exceptions to these sweeping groups by making exclusive grants. In the end, your ACL makes grants to the set of all users, minus the set of all those who should generally be denied, except for a select few for whom permission should be exclusively granted.
Registry Keys Are Securable Resources
What is not immediately obvious to the WS2K3 administrator is that System Registry keys are among the resources eligible for security descriptors. The way Microsoft chose to retrofit the Registry with security features of some sort was to enable administrators to create security descriptors for specific keys, enabling them to deny groups of users (including, most often, other software components) the rights to change their values, or perhaps even to query their values.
But although Microsoft has successfully designed a mechanism for at least some kind of authentication control for Registry keys and their values, it has not made any tool for actually using that mechanism available to the administrator. Developers can use Windows API function calls to access this mechanism, but no general console exists for admins to perform the same functions.
Furthermore, it might not be clear to an administrator to what what key she should deny access, and to whom she should deny that access, unless and until she had access to some detailed audit revealing the very Registry query that has triggered a problemor moreover, until she has a more through comprehension of what the problem is to begin with. A shareware command line utility does exist, enabling individuals to deny access to, say, the root class for handling JPEG images, by any program that is trying to wrest responsibility for that job without permission.
"What Is an Access Control List?" by Keith Brown. From Keith's personal Web site.
"Registry Key Security and Access Rights." Article on MSDN.com.
"Security Identifiers." Article from microsoft.com.