Windows Server Reference Guide

The Purpose of Access Control Lists

Last updated Aug 27, 2004.

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 entity—an 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 nice—called 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 groups—entities 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 problem—or 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.

References

• "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.

Books and E-books

• Robert Cowart, Brian Knittel. "Components Involved in Access Control." From the Que book Platinum Edition Using Windows XP. Preview this book on Safari.