Windows NT Security Theory and Practice

Ruediger R. Asche Microsoft Developer Network Technology Group
Summary

This article is the first of a series of technical papers, describing the implementation and programming of C ++ class layers that encapsulate Windows NT Security application interfaces. This series of papers includes:

"Windows NT Security in Theory and Practice" (Introduction)

"The Guts of Security" (Security class level implementation)

"Security Bits and Pieces" (sample program structure)

"A Homegrown RPC mechanic" (describes the remote communication used by the sample program)

In this article, we will discuss security encryption at a very high level.

Introduction

Security should be quite easy to implement in the operating system, right? That is to say, all the work required to specify a security level for any object is a simple function call, such as GrantAccessTo or DenyAccessTo, right?

Unfortunately, the Windows NT Security application interface (API) does not seem that simple. It contains too many security-related functions, and the work of opening an object for a user is very complicated.

To correctly use the security API, you need to understand the following layers:

The first layer is to understand the data structure: Access Control tables (ACLs), access control elements (ACEs), security descriptors (SDs), and security IDs (SIDs ).
The second level is to understand the semantics of ACLs (although it is not necessary to understand how they work ). Access to the same user may or may not be allowed depending on the order in which ACLs is established.
The third level is to understand how the operating system uses security. Security APIs can be understood as a service set provided by server applications to protect objects from unauthorized user access, the same way as transaction logs help device drivers and applications record errors and confirm that events provide services.
When these services are only used by third-party applications, it is quite easy to understand how security works. However, Windows NT is a secure operating system, and the Network Based on Windows NT is also very dependent on security. Therefore, the method of combining security with the system is vague.

Who needs security?

Before entering any details, you must clarify why security is required. If it is not in the following situations, you do not have to worry about security:

A server application is being written, that is, an application that can be accessed by several users, and the server application only provides a data structure for a subset of these users.

Note that this is a fairly broad definition. The following are examples of programs that meet the conditions.

For a single computer (without a network connection), write a service that runs continuously after Windows NT is started, and multiple users log on and exit from the computer. The information provided by this service is only visible to a few users. For example, to collect usage mode or login data, it may be limited to administrator access.

Many privileges are restricted at the system level. For example, the system registry is protected so that only users with special privileges can add device drivers to the system. This is because of security. For example, a malicious user can use the device driver to monitor user input and steal other users' work. Security also helps system stability. Imagine an unauthorized user installing a crude device driver. When other users work, such a driver will cause a system crash. By limiting the right to register a driver for a new device to a trusted user, this situation can be prevented on Windows NT computers.

Many server programs that work on the network as well as standalone servers benefit from some sort of hook-up with the security system. For example, a database server may serve several users at the same time, and some users cannot view certain data in a given database. Assume that everyone in the company can query the employee database. The administrator needs to access all information about the employee, while others should only see the job title and office number. If you restrict access to fields that contain salary and bonus information, you can allow all people in the company to use the same database without compromising security and confidentiality.

Security micro view

One of the security issues is that the use of secure APIS is nothing new and exciting. Code Compiled by others can rotate the teapot, display animations in the window, pop up the cool Windows 95 control, and send data back and forth through MAPI. security programming is always annoying.

Windows NT Security performance is very complex, in contrast, from the micro level, it is relatively simple. Each Windows NT domain (or domain group) stores the database of the user that the domain knows. To work in a Windows NT domain, you must first use a user name and password to prove yourself. Once the security system proves the password, the user is associated with an access token to identify the user's internal data structure.

The first thing you must know about security in Windows NT is that it is user-centered. That is to say, every line of code that tries to access protected objects must be associated with a special user, the user must use a password to prove his/her identity to the client. Each security check depends on user authentication. For example, writing code to prevent Microsoft Excel from accessing an object is impossible. It can protect an object from being accessed by Joe Blow running Microsoft Excel. However, if Carla Vip is allowed to access this object, she can use Microsoft Excel or other favorite programs, as long as Carla uses a password only known to prove its identity to the client.

Although the security API looks complicated, it only performs two tasks:

Audit: A log entry is generated every time a specific operation is attempted on a specific object.

Restrict object access: the function called by the client program may succeed, and error code 5 (Access denied) will be returned for failure, or failure for other reasons depends on how the server assigns privileges.

The user may not directly see the error message, but a dialog box that says, "You have no privilege to take the eggs out of the tray ." The program in this dialog box may contain the following code lines:

If (! RemoveEggsFromCarton () & GetLastError () = ACCESS_DENIED)

AfxMessageBox ("You do not have the privilege to remove the eggs from the carton ");

Security Mechanism

Windows NT uses two mechanisms that cause access failure and Return Error 5: Confirm permissions and confirm privileges. The permission belongs to the action on the object, such as suspending the thread permission or reading the File Permission. Permissions are always associated with specific objects and known users. For example, the permission to read a file must be associated with a file (permission applied to this file) and a user without or without permission. Similarly, the permission to suspend a thread is useless unless associated with a specific thread and user.

Privileges are pre-defined permissions for system operations. For example, privileges include debugging programs, backing up and restoring storage devices, and loading drivers. Privileges are user-centered, not objects.

To make the distinction between the two more clear, you can look at the data structure that implements permissions and privileges: permissions are specified in the data structure called access control table (ACL. ACL is usually related to objects. The user uses an access token. When a user tries to access a protected object, the access token is checked with the object ACL. The access token contains a unique identifier (Security ID, Or SID) representing the user ). Each permission in the ACL is related to a SID. In this way, the security subsystem knows the permissions related to each user.

On the other hand, the privilege is encoded in the access token, so there is no associated object. To determine whether the user is allowed to perform a privileged-related operation, the Security Subsystem checks the access token.

In addition, the permission requires a description of the behavior (what is the permission? For example, read a file or suspend a thread), and the privilege is not required (user or privileged, or none ). Actions that follow the privileges are hidden in the privileges themselves.

The reason for the privilege encoding in the access token is that most privileges do not consider security requirements. For example, users who are allowed to back up storage devices must be able to bypass file security. Adding a new ACE to each individual file on the hard disk is not feasible to allow access. In this way, the code of the backup storage device first checks whether the user attempting to back up has the backup privilege. If yes, the security of a single file is ignored.

Privileged sets related to access tokens are securely encrypted and cannot be expanded by applications. Server programs can use special permissions and common ing to implement custom security rules.

There are two types of ACLs: DACL and SACL ). DACL controls Object Access and SACL controls audit.

Access Control

In most cases, error 5 is generated internally by the Win32 function unique to Windows NT called AccessCheck. The input of this function includes the user's access token, required privileges, and ACL. An ACL is a list of small data structures (called access control elements or ACE). Each Data Structure defines a user or a group of users, a permission set, and information that is allowed or denied. For example, there may be an ACE in the ACL that says "the permission to take the eggs from the tray explicitly denies giving the users Elephant and Bozo ", the following ACE says, "the permission to take eggs from the tray is clearly granted to user Betty Crocker and all users in the CHEFS group ".

ACL is related to objects and can be dynamically created in server programs. For example, if a file object is associated with an ACL and an application attempts to open the file object at any time, the ACL will be queried to determine whether to allow users running the application to open the file.

The AccessCheck function is called internally by many system functions, such as CreateFile (when a user attempts to open a file on an NTFS partition or named pipe) and OpenFileMapping. However, Win32 server programs can directly call AccessCheck to protect any objects to be protected.

Note that security API functions are only called by server programs. Customers do not need or directly use security. Windows NT security that the customer once saw is error 5. This makes Windows NT Security unnecessary to consider the software running by the customer. What is needed is the ability of the server to confirm the customer in the security database of the domain and translate the requests received from the customer into server-side function calls. This function either implicitly calls AccessCheck, or sends or does not send the result based on the server-side AccessCheck output.

The confusing part of Windows NT security is that calls to AccessCheck may be very vague. For example, the driver installation function of Windows NT monitoring device is a very vague concept. Which object does the user want to access when trying to add a device driver "? Where can the system call AccessCheck and where can the error message be displayed to the user if necessary?

In the example of a device driver, the answer is not too difficult: Because the device driver and the system use the registry (Windows NT explains each entry by browsing the registry subtree, run the driver binary file specified in the separate registry key to load the device driver.) The Windows NT protects the registry key, it is an object that can be obtained in Windows NT. At the Win32 API layer, any attempt to operate the registry will be translated into a function used by the Registry. For example, RegOpenKey calls AccessCheck internally.

In addition to registry protection, the driver's binary files also have security issues. A hacker who fails to access the registry is still able to replace the original driver execution file with a copy of the driver with additional features. This process is not required