Tokens and masks help you play the Windows 2000 security game

With security concerns firmly planted in the IT landscape, it may be time to beef up your background in Windows 2000 security. In this Daily Drill Down, Brien Posey explains how ACLs, access tokens, and access masks work together to secure a network.

Most techs understand that Windows 2000 uses various access control lists to help stay secure. However, that limited amount of knowledge won’t get you very far when you’re facing a serious security problem. Don’t be like most techs; instead, learn how access control lists work in conjunction with access tokens and access masks to ensure that Windows 2000 stays secure. Once you have a complete understanding of how these Windows 2000 security principals work, you can secure your network with confidence, when most techs couldn’t.

In this Daily Drill Down, I’ll offer a behind-the-scenes look at the Windows 2000 security game—complete with masks and tokens.

Access tokens
The various types of access control lists interact with each other through the use of access tokens. An access token is an object that’s automatically created when a user logs in, and then, when the user logs out, the access token is destroyed. Each user has an individual access token, and every time a user logs on, a new access token is issued.

Perhaps the best way of describing an access token and how it works is to compare a Windows 2000 system to a secure building. An access token is similar to a key card that allows the user to open certain doors inside of a building. Like the key card, the access token is a form of identity. The main difference between the two is that while a key card is usually used on a daily basis, an access token is used only once.

The access token is nothing more than a list that contains the user’s security identifier (SID) and the SIDs of all of the groups that the user belongs to. An access control list contains access control entries, which, in turn, contain the user SIDs or group SIDs that have access to the object protected by the list. When a user attempts to access a resource, Windows compares the SIDs from the access token to the SIDs in the access control list to determine whether the user has access to the resource.

Read more!
To learn more about access control lists read “Learn the difference between ACLs, DACLs, and SACLs.” In this Daily Drill Down, Talainia Posey explains what the various access control lists are used for in Windows 2000.

Access by operation
Windows is designed to run multiple processes, each made up of one or more threads. Some of these processes, such as trying to read a file or run an executable program, occur at the user level. Other processes, such as making sure that a critical service is still running, are run automatically by the system. Windows must have a way of knowing if a process is being run by a user or by the system.

Any processes that a user launches are given a copy of the access token that the user obtained upon login. The access token helps control whether the user can run the application and access any associated data. If access tokens weren’t issued to individual processes, it might be possible for the application to open the file, even if the user who was running the application didn’t have rights to do so.

The access mask
Windows never issues permission to an object as a whole. Instead, Windows grants permissions on an operation basis. For example, a user might be given access to read a file or write to a file, but the user is never given access to the entire file. Controlling operation-based access is the job of the access mask.

Within a discretionary access control list (DACL) or a system access control list (SACL), access masks are used to define all possible actions for an object. There is a separate set of access control masks for each entry on the access control list. Each individual set of access control masks contains a separate access control mask for each type of access that a process may ask for. Access control masks support the following types of access rights:
  • Specific access rights: Specific access rights aren’t actually rights that are granted to users and groups but are rather a set of definitions that describe the various actions that could potentially be performed on a securable object. An example of a specific access right is the FILE_READ_DATA right, which relates to read permissions for a file, or the FILE_APPEND_DATA right, which relates to write access to a file. In all, there are 16 different specific access rights. Not every object can be assigned all 16 permissions. The permissions that can be assigned to an object depend heavily on the object type. For example, a file object wouldn’t have the same types of specific access rights as an Active Directory object.
  • Standard access rights: Standard access rights are permissions that are always applied to an object, regardless of what other permissions may exist. An example of a standard access right is Write_Owner, which gives the object’s owner permission to update the object. Another standard access right is the DELETE flag, which determines whether a user or group has the authority to delete the object.
  • Generic access rights: Generic access rights are an interface through which administrators may grant permissions. Anytime that administrators grant a user read (R), write (W), or execute (X) permissions to a resource, they are actually using a generic access right. The generic access acts as a pointer to a specific access right or to a standard access right. For example, if an administrator granted read (R) permissions to a user for a file, the read (R) generic permission is actually a pointer to the FILE_READ_DATA specific right.
  • SACL access rights: An access mask can contain several different types of SACL access right information. For example, a SACL access right could tell Windows if a particular action on a specific object by a specific user or group should be audited. Additionally, a SACL access right may also be used to tell the system if the user or group in question has the rights to change the auditing policy for the object.

The anatomy of an access mask
An access mask outlines the permissions that each access control entry on an ACL has for the object. An access control mask is actually nothing more than a 32-bit stream of binary numbers. Each position in the bit stream has a specific meaning in relation to access control for the object. For example, the final bit in the series controls the generic read permission. If the bit is set at “1,” then the generic read permission is enabled. If this bit is set to zero then the generic read is disabled. To help you gain a better understanding of how the access control process works as a whole, here is a general overview of the anatomy of an access mask.

Bits zero through 15 are used for specific access rights. Since there are a total of 16 possible specific access rights, each of these possible specific access rights is represented by one of the first 16 bits.

Bits 16 through 22 are used to control the standard access rights. Bit 23 is a flag that determines whether the user or group has the rights to modify the SACL for the object. Bits 24 through 27 are reserved for use by the operating system.

Bits 28 through 31 are used to control the generic access rights. Bit 28 controls the generic all permission (used for full access). Bit 29 controls the generic execute permission. Bit 30 controls the generic write permission, while bit 31 is used for the generic read permission.

Asking for access
To ask for access to a resource, the process sends a request to the system in a format similar to the one used by the access mask. If an access mask can be found that matches the request, then the system generates a copy of the access mask, known as the granted access mask, and sends it to the process that requested the access.

Once the process has the granted access mask, the object may proceed with the access. If, on the other hand, the system is unable to find a matching access mask, then all of the bits in the granted access mask are set to zero before the granted access mask is passed to the process. The full set of zeros explicitly denies the process the requested right.

The access control process as a whole
When a process attempts to access an object, the process looks for the existence of a DACL. If the DACL is nonexistent, then the system automatically generates a granted access mask and sends the mask to the user. If the DACL exists but is empty, then the system automatically generates a granted access mask consisting of all zeros and sends it to the process, essentially denying access.

Then the system checks to see if the process is asking for access to the SACL. If the process is asking for access to the SACL, then the system checks the access mask to see if bit 23 is set to zero or 1. If bit 23 is set to 1, then the system prepares a granted access mask that allows the process access to the SACL.

In the next phase of the access control process, the system checks to see if the user is asking for read or modify (write) access or for permission to change the object’s owner. If the process is asking for any of these types of access, then the system compares the user’s SID against the object’s owner’s SID. If the user making the request is found to be the object’s owner, then the necessary granted access mask is created and passed to the process.

At this point, Windows 2000 determines whether the user has the necessary level of access to the object. This is a fairly complicated process. The process begins by determining which set of permissions the object has inherited from parent objects. The system then begins processing each access control entry from top to bottom, looking for any access control entries that fit the request.

If a match is found, then the necessary bits are set in the granted access mask, and the granted access mask is sent to the user. However, things aren’t always that simple. For example, imagine that a process asks for read and execute permissions to a file but no access control entry exists that grants the associated user these permissions.

Suppose that as the system checks the access control entries, it encounters a permission that grants the user (or process) read access to the file. In such a situation, the granted access mask would be updated to reflect the read permission but wouldn’t be immediately sent to the process that’s requesting the access. Instead, the system would continue searching the access control entries to see if any of the user’s group memberships allow execute permissions for the file.

If the system finds a valid execute permission, then the execute permission is appended to the read permission on the granted access mask, and the granted access mask is then sent to the process that requested access, essentially allowing the operation to proceed. If, however, the necessary execute permission is not found, then the granted access mask is set to all zeros and is then passed back to the process. Setting the granted access mask to all zeros cancels out the previously issued read permissions to the file.

In such an operation, it’s important to remember that the read permissions still exist, because the ACL entry that issues the read permissions still exists. However, access is granted on an operation basis. This means that if a process asks for read and execute permissions, the process will either receive both the read permission and the execute permission or nothing at all. Windows will never issue a subset of the requested permissions.

Putting it all together
After reading about all of the intricacies involved in the way that access tokens work, you may be wondering how the access tokens relate to access control lists (ACLs) and the corresponding access control entries. To simplify things, remember that an access control entry is nothing more than a list of SIDs, as is an access token. The entire access control process is initially based on whether a match can be found between the two lists of SIDs. Once a match is found, the process compares the processes’ requested permissions to the processes issued permissions to determine whether access should be granted.

In the end, ACLs, DACLs, and SACLs work together to make up the system’s security policy, but how they go about doing it is more complex. Using access tokens and access masks, the control lists make sure your system is safe and secure. Now that you know how they work, you can more easily identify problems that can occur when granting access.

Editor's Picks

Free Newsletters, In your Inbox