Chapter 5: Managing Access Control

One of the most powerful and, at the same time, most complicated areas in security is that of Access Control Lists (ACL). ACLs are used to secure resources for both local and remote access. Per the official definition, ACLs enumerate which subjects have what type of access to which objects. Subjects in this sense are users and any program acting on their behalf. Objects are everything else that the subjects might want to access. Subjects are often referred to as "security principals" in Windows. A security principal is essentially equivalent to a subject, an entity that can be granted or denied access to something.

The net result of an ACL is that a user has a set of permissions to an object, such as a directory. These permissions can be the result of the user's direct permissions or group memberships. The effective permissions on a folder are show in Figure 5-1.

Figure 5-1: The Effective Permissions tab evaluates permissions for any user.

This chapter is all about ACLs, and specifically how they have changed in Windows Vista and what that means for you, as the administrator of one or more Windows Vista systems. While a comprehensive coverage of ACLs is beyond the scope of this book, we will introduce you to enough of the basics to allow you to understand how access control is changing in Windows Vista. We start by reviewing a bit of terminology about ACLs to ensure that we have a common language for the discussion to follow.

Access Control Terminology

To understand how Windows Vista modifies how you work with ACLs you need to understand some of the basics about what ACLs are and how they work. In Chapter 4, we covered security identifiers (SID) and security tokens. In this chapter, we build on that with a review of the basic concepts related to ACLs. The reader who is comfortable with these concepts may wish to skip this section entirely. For a reader who is not familiar with ACL concepts at all, this section may not go into sufficient depth. However, if you feel you just need a review, this section should get you going and prime you for what is to come.

Securable Object

As mentioned in the chapter introduction, ACLs are applied to objects-more specifically, to securable objects. A securable object is, just as the name implies, an object that can be secured with an ACL. That covers pretty much any object you can think of as it turns out. Examples of securable objects, in Windows Vista, are:

• Files

• Directories

• Registry keys

• Services

• The Event Logs

• Network ports (new with Windows Vista)

• Named pipes

• A process

• An event

• Kernel objects

All objects that can be managed can also be secured, but unless you are a programmer, you will not be securing things like kernel objects, and you will probably not work with security in named pipes either. However, the other ones are very useful to work with. It is worth noting that with Windows Vista, and the new Advanced Firewall that comes with it, you can put an ACL on a port. We talk more about that in Chapter 11.

Access Control List

So far we have used the term "Access Control List" to describe a way to specify permissions on objects. This usage, although very common, is not technically correct, as it actually refers to how a Discretionary ACL (DACL) functions. As the name implies, a DACL is at the discretion of the system administrator and is used to control permissions. There are two other forms of ACLs: Mandatory ACLs (MACL) and System ACLs (SACL). Windows Vista supports SACLs and DACLs, but not MACLs. A SACL is identical in structure to a DACL, but specifies auditing to take place instead of permitted access. A MACL is managed and enforced by the system, and is not up to the system administrator to manage. It also specifies permitted access, but access based on object labels, as opposed to enumerated permissions. For example, if an object is labeled Top Secret, then if a user has Top Secret access, the user may access the object; if not, the access is denied. The system administrator cannot change this other than by re-classifying either the object or the user. MACLs are supported only in a few, specialized operating systems.

From now on, we will use the term DACL when we refer to an ACL specifying permissions, the term SACL to refer to an ACL specifying auditing, and the term ACL to refer to the general construct.

Security Descriptor

Every securable object has a security descriptor (SD). The SD is a structure that is associated with the object and is referenced whenever the object is accessed.

In the SD we specify who owns the object, which primary group that user is a part of, and the DACL and SACL applied to the object.

Access Control List Entry

When you look at an ACL you will see that it can specify several different types of access for the same user and access for several different users. Each of these entries is an ACL Entry (ACE). An ACL may contain many ACEs, up to about 65,000 theoretically. An ACE consists of the security identifier (SID) for the subject (see Chapter 4 for more information on SIDs), an access mask that specifies the access the subject has to the object, and a few flags that alter how the ACE is evaluated.

ACL Representations

There are several ways of representing an SD and its ACLs. Internally to the system they are a set of structures and pointers (C-language programming constructs that are familiar to every C/C++ programmer), containing fields using bitmasks to specify the contents of an ACL. When programmers and advanced system administrators work with SDs and ACLs they specify them in a language called Security Descriptor Definition Language (SDDL). SDDL is extremely powerful, and can get quite complicated. A thorough description of it is beyond the scope of this book. The interested reader is referred to the Platform Software Developers Kit (SDK), which can be downloaded for free from http://www.microsoft.com/downloads/results.aspx?pocId=&freetext=platform%20sdk&DisplayLang=en, and Chapter 17 of Protect Your Windows Network: From Perimeter to Data by Jesper M. Johansson and Steve Riley. Both discuss SDDL at length-the former with an emphasis on using SDDLs in software development, and the latter with an emphasis on using them in system administration.

Inheritance

Many objects, such as files, directories, and registry keys, allow propagation of ACEs from parents to children through inheritance. Inheritance can be extremely granular, and a single ACL may, and frequently does, have some ACEs that are inherited, and some that are not. ACEs can be inherited by children that are containers, such as directories; by children that are objects, such as files; or both. Container inheritance is specified with the flag CI in SDDL, while object inheritance is specified with OI. You may also see the flag IO, which means "Inherit Only." An ACE with the IO flag does not apply to the object it was specified on, only to its children. You will also see an I or ID flag, depending on which tool you are using. In either case it stands for "Inherited," meaning that the ACE was inherited from a parent.

Inheritance is an extremely powerful concept and can greatly reduce your administrative burden if you learn how to use it to your advantage. It can also completely destroy your system to the point where it is easier to flatten the whole thing and rebuild it than to fix it. This is especially true if you modify the default ACLs. The inheritance model will propagate changes deeply down the tree, and generally restoring the original ACL becomes impossible.

This is one of the major reasons why Microsoft has decided that it cannot support systems configured with third-party security guides. There are numerous instances where people applied inheritance incorrectly and ended up destroying their system. For instance, one site used an unsupported security configuration guide from a third party and propagated it with group policy without testing it first. The result was that the Administrator's profile was world readable and the recycle bin did not work. Both of those problems were somewhat mitigated, however, by the fact that users could no longer log on to the system. When they contacted Microsoft for a solution they were informed that the only guaranteed solution was to flatten and rebuild 10,000+ systems. They opted instead for a manual restore, which cost tens of thousands of dollars in consulting fees and weeks worth of lost productivity. Microsoft even published a knowledge base article highlighting the dangers of this and other unsupported security tweaks: http://www.support.microsoft.com/kb/885409.