A Method of Choosing Good ACLs

Over the past few months I ve come to live by the following security maxim when performing security reviews: You must account for every ACE in an ACL. In fact, if you can t determine why an ACE exists in an ACL, you should remove the ACE from the ACL. As with all engineering processes, you should design your system using a high-level analysis technique to model the business requirements before creating the solution, and the same philosophy applies to creating ACLs. I ve seen many applications that have ACLs designed in an utterly ad hoc manner, and this has led to security vulnerabilities or poor user experiences.

The process of defining an appropriate ACL for your resources is simple:

Determine the resources you use.
Determine the business-defined access requirements.
Determine the appropriate access control technology.
Convert the access requirements to access control technology.

First and foremost you need to determine which resources you use for example, files, registry keys, database data, Web pages, named pipes, and so on and which resources you want to protect. Once you know this, you ll have a better understanding of the correct ACLs to apply to protect the resources. If you can t determine what your resources are, ask yourself where the data comes from that should lead you to the resource.

Next you should determine the access requirements for the resources. Recently I had a meeting with a group that used Everyone (Full Control) on some critical files they owned. The rationale was that local users on the computer needed to access the files. After I probed the team a little more, a team member said the following:

All users at the computer can read the data files. Administrators need to perform all tasks on the files. However, users in accounting should have no access to the files.

Take note of the emphasized (roman) words. For those of you who have used Unified Modeling Language (UML) use cases, you can see what I m doing extracting key parts of speech from the scenario to build business requirements. From these business requirements, you can derive technical solutions in this case, access requirements used to derive access control lists.

A useful introduction to UML is UML Distilled: A Brief Guide to the Standard Object Modeling Language, 2nd Edition (Addison-Wesley Publishing Co, 1999), by Martin Fowler and Kendall Scott.

Remember that ACLs are composed of ACEs and that an ACE is a rule in the following form: A subject can perform an action against an object or Someone can perform something on some resource. In our example, we have three ACEs. All users at the computer can read the data files is a rule that translates nicely into the first ACE on the data files: Interactive Users (Read). It s classic noun-verb-noun. The nouns are your subjects and objects, and the verb determines what the ACE access mask should be. The access mask is a 32-bit value that defines the rights that are allowed or denied in an ACE.


	The Interactive Users group SID applies to any user logged on with a call to LogonUser when dwLogonType is LOGON32_LOGON_INTERACTIVE.

Interactive Users is the same as All users at the computer except in the case of users of Microsoft Terminal Server. If you decide that users of Terminal Server need access too, you can add the Remote Interactive User (Read) ACE to the ACL in Windows XP. Also, users who are accessing the computer via FTP or HTTP and are authenticated using Basic authentication are logged on interactively.


	You can also use the Terminal Server User identity to represent users of Terminal Server, but the identity exists for backward compatibility with Windows NT 4, and its use in Windows 2000 and Windows XP is discouraged.

You should follow this process for all subjects (users, groups, and computers) until you create a complete ACL. In this example, we end up with the ACL shown in Table 4-1.

Table 4-1 Access Control List Derived from Business Requirements
Subject	Access Rights
Accounting	Deny All Access
Interactive Users	Read
Administrators	Full Control
SYSTEM	Full Control


	When building ACLs using code, you should always place deny ACEs at the start of the ACL. ACLs built using the Windows ACL user interface will do this for you. Failure to place deny ACEs before allow ACEs might grant access that should not be allowed.

I once filed a bug against a team that had an Everyone (Full Control) ACL on a named pipe the application created. The developer closed the bug as By Design, citing that everyone had to read, write, and synchronize to the pipe. It was fun reopening the bug and telling the developer that she had just defined what the ACL should be!


	Good ACLs are paramount if your application might be running in a Terminal Server environment. Many users might have access to more code-based resources, such as named pipes and shared memory, and poor ACLs can increase the chance that malicious users can affect the system s operation by denying other access to resources.

Take a look at the Weak Permissions on Winsock Mutex Can Allow Service Failure Microsoft security bulletin (MS01-003), issued in January 2001 and available at www.microsoft.com/technet/security, for information about the implications of weak ACLs and Terminal Server.

Effective Deny ACEs

Sometimes, when defining the access policy for resources, you ll decide that some users should have no access to a resource. In that case, don t be afraid to use a deny ACE. For example, during the design of Internet Information Services 6, the decision was made to explicitly disallow anonymous users access to certain powerful applications, such as Ftp.exe, Cmd.exe, and so on. This helps mitigate the threat of hackers remotely executing these dangerous applications.

Determining access control requirements is as simple as writing out the access control rules again, based on the business rules for the application and then looking for verbs and nouns in the requirements. Then you can determine which access control technologies are appropriate and how to configure the mechanisms to comply with the access control policy.