Access Control Lists

[Previous] [Next]

Windows 2000 protects securable resources from unauthorized access by employing discretionary access control, which is implemented through discretionary access control lists (DACLs). DACLs, usually abbreviated to ACLs, are a series of access control entries (ACEs). Each ACE lists a principal and contains information about the principal and the operations that the principal can perform on the resource. Some people might be granted read access, and others might have full control. The type of ACE depends on the type of securable object.

A securable object is any object that has a security descriptor containing security information, such as the owner's SID and ACL data, about the object. Examples of securable objects include the following:

• NTFS files and directories
• Named and anonymous pipes
• Processes and threads
• Registry keys
• Services
• Printers
• Network shares
• Job objects

An ACL is a simple data structure. It contains a series of owner information and zero or more ACEs. Each ACE contains a SID and access information pertaining to that SID, such as read, write, open, create, and so on. ACLs are applied to resources requiring protection and are referred to as discretionary because deciding who has what degree of access to the object is at the discretion of the object owner. For example, you might decide that only three other people should have access to a file you control: Bob (Read Only), Alice (Read Only), and Cheryl (Full Control).

In this case, the ACL contains three ACEs: two that give Bob and Alice read-only access to the resource, and one that gives Cheryl full control, as shown in Figure 3-5. Note that in this case an administrator will be denied access if he or she attempts to access the resource because no explicit ACE exists that would allow anyone but Bob, Alice, and Cheryl access; this is what is meant by discretionary access.

Figure 3-5. The ACL for a file named Confidential.doc.

Windows 2000 also includes support for explicitly denying access to an object by using deny permissions. For example, if you want all users (Everyone) except for Richard to have access to a file, you'd set the following: Everyone (Read) and Richard (Deny Full Control).

Because denies are always checked before allows, Richard will always be denied access to this object. For this reason, never deny Everyone access to an object. You will be warned of the ramifications if you do this from the Windows shell.

In addition, different objects have different permission types:

• Files can have their permissions set and can be written to, read from, and created.
• Printers can be printed to or managed.
• Active Directory objects can have specific settings on object properties such as the ability to read a user's certificates or set their e-mail address.
• Registry keys can be queried, written to, and have subkeys created and deleted.

What Happens to Secured Resources if the Owner Leaves?

Imagine that an employee creates some secured resources that do not allow the administrator to access the resources, and then the employee leaves. What happens to the files? The owner of an object can always create any ACL on any resource he or she owns, but an administrator can always take ownership of that resource. Note, however, that the administrator cannot give ownership back. Instead, the administrator can take ownership of the resource and then set new ACLs. Because the administrator cannot take ownership of a resource, change ACLs, and then reassign ownership of the resource back to the original owner, the possibility of abusing the ability to take ownership is slim.

To look at the owner of a file, perform the following steps:

1. Right-click the resource.
2. Choose Properties from the context menu.
3. Click the Security tab.
4. Click the Advanced button.
5. Click the Owner tab.

If you either have permission to take ownership—there is a Take Ownership permission that an owner can apply to a resource—or are an administrator, you can take ownership by selecting yourself in the Change Owner To: list box, as shown in Figure 3-6.

Figure 3-6. Viewing a file's owner.

How Access Is Determined

When a principal attempts to access a resource, Windows 2000 performs a simple DACL check. It does this by checking the SIDs in the user's token for the type of access requested (for example, a call to CreateFile or OpenRegKey for read, write, and so on) against the SIDs in each ACE of the resource's ACL. Windows 2000 denies access to the object if none of the ACEs allow the user access or if an ACE denies the user access; otherwise access is allowed.

There is one other step in Windows 2000. When a restricted process or thread tries to access a securable object, the system performs two access checks: one using the token's enabled SIDs and another using the list of restricting SIDs. Access is granted only if both access checks allow for the requested access. (We'll discuss restricted tokens shortly.)

It's important to note that an application acting on behalf of a user (that is, impersonating the user) should ask only for the access rights it requires to perform its tasks and no more. If the application asks for read, write, and delete access but the resource allows read access only, the application will be denied access—it won't be granted read access.

ACLs at the Command Line

You can view and update ACLs on an NTFS partition from the command line by using the CACLs.exe tool. The CACLs.exe tool lets you display, edit, or replace ACLs on files and directories. The following is an example of how to grant the Everyone group read access and the Administrators group full control for a file named info.txt:

 cacls info.txt /G Everyone:R Administrators:F 

You can display the ACLs on a file if you type cacls info.txt:

 C:\WINNT>cacls info.txt C:\WINNT\info.txt Everyone:R  BUILTIN\Administrators:F 

ACL Tools in the Resource Kit

The Microsoft Windows 2000 Server Resource Kit includes a number of ACL-related tools, including PermCopy.exe, ShowACLs.exe, SubInACL.exe, SvcACLs.exe, and XCACLs.exe, to make command-line administration easier. (As with CACLs.exe, these tools work only on NTFS partitions.)

PermCopy.exe copies share-level (Full Control, Read, Change) and file-level (Full Control, Modify, Read & Execute, Read, Write, Traverse Directory) ACLs from one share to another.

ShowACLs.exe details access rights for files and folders. The most useful feature of ShowACLs.exe is the ability to show permissions for a particular user.

SubInACL.exe administrators can obtain security information on files, registry keys, and services, and transfer this information from user to user, from local or global group to group, and from domain to domain.

SvcACLs.exe sets ACLs on service objects, enabling administrators to delegate control of services when using the Services administration tool. For example, an administrator could grant a nonadministrator such as EXAIR/Marc the rights to control the Web server with the following command line:

 svcacls w3svc g:exair\marc rx 

XCACLs.exe is a finer grained version of CACLs.exe; it offers more control over how you set and manipulate ACLs than CACLs.exe.

The Principle of Least Privilege

As a user, you should always execute code with just enough privilege to get the job done and no more. This helps prevent accidental or malicious damage. Because all user code executes in the context of the user, if the user is a privileged account, damage can be massive.

The simplest solution is to never log on as an administrator unless you absolutely must. Any code you run, whether good or malicious, will run with all the privileges assigned to the administrator account, which might cause serious damage if you execute code infected with a virus.

Windows 2000 extends support for the concept of least privilege by providing restricted tokens and secondary logon, which the following sections will describe.

Restricted tokens in practice

If you require only privileges X and Z to perform a task but your token is capable of performing tasks requiring X, Y, and Z, you should remove privilege Y from your token. Restricted tokens support the concept of reducing the default capability of a token.

A good example of this is Web browsing: While you're browsing the Web, your application should run at the lowest possible privilege just in case you accidentally execute malicious code. If you execute such code, the damage will be contained because the code runs with fewer privileges than you normally have. The APIs supporting restricted tokens are available in Windows 2000 only and are described in Table 3-5.

Table 3-5. Restricted token APIs in Windows 2000.

API	Comments
CreateRestrictedToken	The CreateRestrictedToken function creates a new access token that is a restricted version of an existing access token. It can be called to remove privileges, set deny attributes to SIDs, and specify restricted SIDs.
IsTokenRestricted	The IsTokenRestricted function indicates whether a token contains a list of restricting SIDs.
CheckTokenMembership	The CheckTokenMembership function determines whether a specified SID is enabled in a token.

Secondary Logon

As already mentioned, you should always log on to a computer running Windows 2000 using a nonadministrator user account. You should not add yourself to the Administrators local group, and you should avoid running your computer while logged on as an administrator. One of the authors wrote a small program he places in the Startup group for all users on his computers—it reminds him if he is logged on as an administrator. This simple tool, RUAdmin.exe, is included on the companion disc.

For most computer activity, log on as a member of the Users or Power Users group. If you need to perform administrative tasks, you can log off and log on again as an administrator, in which case you would lose your current work, or you can use the Secondary Logon service, which is also called the RunAs service in Windows 2000.

RunAs allows a user to run specific tools and programs with different permissions than the user's current logon provides. For example, the following command will start another command shell but run it as the local administrator rather than the currently logged on user:

 runas /user:EXAIR\administrator cmd 

After entering the command, the user is prompted to enter the administrator's password for the EXAIR domain. Figure 3-7 shows a command shell created by RunAs running as administrator.

Figure 3-7. A command shell created by RunAs running as administrator.

If you create a shortcut to an application on your desktop, you can invoke the RunAs service by holding down the shift key and right-clicking the shortcut on the desktop and choosing Run As from the context menu. You are then prompted to enter the account information; by default, the user name will be the local administrator, as shown in Figure 3-8.

Figure 3-8. Selecting a user account to run a command under.

You can make the Run As Other User dialog box appear each time you activate a shortcut by selecting the Run As Different User option—see Figure 3-9—in the Properties option of a shortcut, like so:

1. Right-click the shortcut in question.
2. Choose Properties from the context menu.
3. Select the Run As Different User check box.

Figure 3-9. Desktop shortcut properties, including the ability to run as a different user.

NOTE

---

You will not be given the opportunity to use RunAs if you hold down the shift key and right-click the Microsoft Internet Explorer icon on your desktop. You can work around this by creating a shortcut to IExplore.exe; all shortcuts have the RunAs capability.

As already mentioned, the general philosophy is to perform day-to-day tasks as a user or power user, perform dangerous tasks with low privilege, and perform administrative tasks by using RunAs. Figure 3-10 shows an example of how you can accomplish this and use your Windows 2000 computer securely.

Figure 3-10. Changing privileges while performing day-to-day tasks.

In this example, the user is running as a user or power user for most tasks, such as word processing, spreadsheet work, and browsing the corporate intranet. However, for tasks that involve communicating with unknown and distrusted users, the user drops down to a lower privilege by using either restricted tokens or a lower privilege account through the RunAs service. For higher privilege requirements, such as backing up files (which requires the Back Up Files And Directories right) and debugging programs (which requires the Debug Programs right), the user can use RunAs to run as an account with greater privilege for the duration of the task. To use the RunAs functionality, the RunAs service must be running.

Wouldn't It Be Easier Just to Run as an Administrator?

Yes, it would be easier; there'd be no need to use RunAs or similar functionality. However, you'd also be more vulnerable to attack. One of the reasons viruses spread and Trojan horse programs do so much damage is because the user account under which the malicious code is executing is a privileged account. Restricting the account's capabilities helps limit the damage caused by such malware.

In short, do not run as the administrator or as a user in the local administrator's group unless you absolutely must do so.

Checking process access tokens

You can check the default token, and hence the user account, associated with a process by using the Pulist.exe tool in the Microsoft Windows 2000 Server Resource Kit. The following Pulist.exe sample output is interesting because it shows that three copies of Internet Explorer are running, each as a different account:

 C:\WINNT>pulist Process   PID  User Idle   0 System   8 smss.exe   160  NT AUTHORITY\SYSTEM csrss.exe   184  NT AUTHORITY\SYSTEM winlogon.exe   204  NT AUTHORITY\SYSTEM services.exe   232  NT AUTHORITY\SYSTEM lsass.exe   244  NT AUTHORITY\SYSTEM scardsvr.exe   364  NT AUTHORITY\SYSTEM inojobsv.exe   608  NT AUTHORITY\SYSTEM llssrv.exe   644  NT AUTHORITY\SYSTEM regsvc.exe   792  NT AUTHORITY\SYSTEM mstask.exe   812  NT AUTHORITY\SYSTEM explorer.exe   1388 EXAIR\cheryl wcescomm.exe   1180 EXAIR\cheryl dnetc.exe   1496 EXAIR\cheryl OUTLOOK.EXE   1168 EXAIR\cheryl MAPISP32.EXE   988  EXAIR\cheryl IEXPLORE.EXE   1628 CHERYL-LAPTOP\Administrator cmd.exe   1616 EXAIR\cheryl IEXPLORE.EXE   868  CHERYL-LAPTOP\LowPriv IEXPLORE.EXE   1868 EXAIR\cheryl WINWORD.EXE   1696 EXAIR\cheryl pulist.exe   832  EXAIR\Cheryl 

Audit ACEs

Windows 2000 includes another kind of ACL called a System ACL (SACL). SACLs are often referred to as audit ACEs. Rather than checking access to a resource, a SACL generates audit messages for attempts to access the resources. The results are then stored in the security event log.

To audit access to specific files (or parts of the Registry or Active Directory), you must apply SACLs to the files in question and configure Windows 2000 to log such auditing events. The following sections describe the required steps.

Step 1: Applying SACLs to files and/or directories

You need to perform the following steps on every object or group of objects you want to audit:

1. Open Windows Explorer.
2. Navigate to the directory or files in question.
3. Right-click the directory or files in question.
4. Choose Properties from the context menu.
5. Click the Security tab.
6. Click Advanced.
7. Click the Auditing tab. You do not have appropriate privileges if the tab is not available (or the directory or files are not on an NTFS partition).
8. Click Add.
9. Select a user, computer, or group; commonly, you'll select the Everyone group.
10. Click OK.
11. Select the access type you want to audit. Don't forget that you can audit both successful and failed events.
12. Click OK three times.

Step 2: Configuring Windows 2000 to audit file/object access events

You need only perform this step once. However, you should turn off this option if you're not auditing for file and object access, because the security logs can fill up quickly.

1. Open the Local Computer Policy tool.
2. Navigate to Computer Configuration, Windows Settings, Security Settings, Local Policies, Audit Policy.
3. Double-click Audit Object Access.
4. Select Success And/Or Failure Attempts.
5. Click OK.
6. Close the Local Computer Policy tool.

Note that local policy is overridden if you have defined a domain-level policy through Group Policy.