Security

Our discussion of security focuses on accessing resources over a network. However, before we can discuss how security is enforced on resources over a network, we need to discuss security basics on a local machine. Windows NT and Windows 2000 provide the capability to locally and remotely control access to system resources such as files and directories. These resources are considered securable objects. When an application attempts to access a securable object, the operating system checks whether an application has access rights to that object. The three basic access types are read, write, and execute privileges. Windows NT and Windows 2000 accomplish access control through security descriptors and access tokens.

Security Descriptors

All securable objects contain a security descriptor that defines the access control information associated with an object. A security descriptor consists of a SECURITY_DESCRIPTOR structure and its associated security information, which includes the following items:

• Owner Security Identifier (SID) Represents the owner of the object.
• Group SID Represents the primary group owner of the object.
• Discretionary Access Control List (DACL) Specifies who has what type of access to the object. Access types include read, write, and execute privileges.
• System Access Control List (SACL) Specifies the types of access attempts that generate audit records for the object.

Applications cannot directly manipulate the contents of a security descriptor structure. A descriptor can, however, be manipulated indirectly through Win32 security APIs that provide functions for setting and retrieving the security information. We will demonstrate this at the end of this chapter.

Access control lists and access control entities

The DACL and SACL fields of a security descriptor are access control lists (ACLs) that contain zero or more access control entities (ACEs). Each ACE controls or monitors access to an object by a specified user or group. An ACE contains the following type of access control information:

• A SID that identifies the user or the group that the ACE applies to
• A mask that specifies access rights such as read, write, and execute privileges
• A flag that indicates ACE type—allow-access, deny-access, or system-audit

Note that system audit ACE types are used only in SACLs, while allow-access and deny-access ACE types are used in DACLs. Figure 2-2 shows a file object with an associated DACL.

Figure 2-2. File object with an associated DACL

If a secured object does not have a DACL (its DACL has been set to a null value using the SetSecurityDescriptorDacl API function), the system allows everyone full access. If an object has a DACL, the system allows only the access that is explicitly allowed by the ACEs in the DACL. If there are no ACEs in the DACL, the system does not allow access to anyone. Similarly, if a DACL has some allow-access ACEs, the system implicitly denies access to all users and groups not included in the ACEs.

In most cases, you need to specify only allow-access ACEs, with the following exception: if you include an allow-access ACE for a group, you might have to use deny-access ACEs to exclude members of that particular group. To do this, you must place a user's deny-access ACE ahead of a group's allow-access ACE. Note that the order of the ACL is important because the system reads the ACEs in sequence until access is granted or denied. The user's access-denied ACE must appear first; otherwise, when the system reads the group's access-allowed ACE, it will grant access to the restricted user.

Figure 2-2 shows how to set up a DACL that grants read access to a group named Net Team. Let's assume that the Net Team group consists of Anthony, Jim, and Gary and we want to grant read access to everyone in the group except Anthony. To do this, we must have a deny-access ACE for Anthony set before the allow-access ACE for the Net Team. Figure 2-2 also includes an allow-access ACE to grant Jim write access. Remember that applications do not directly manipulate ACLs; instead, they use security APIs to perform these transactions.

Security identifiers

We have noted that security descriptors and ACEs for securable objects include a SID. A SID is a unique value used to identify a user account, a group account, or a logon session. A security authority, such as a Windows NT server domain, maintains SID information in a security account database. When a user logs on, the system retrieves the user's SID from the database and places it in a user's access token. The system uses the SID in the user's access token to identify the user in all subsequent interactions with Windows NT security.

Access Tokens

When a user logs on to a Windows NT system, the system authenticates the user's account name and password, which are known together as login credentials. If a user logs on successfully, the system creates an access token and assigns it the user's SID. Every process executed on behalf of this user will have a copy of this access token. When a process attempts to access a secured object, the SID in the access token is compared with access rights assigned to SIDs in DACLs.