One objective of the Windows NT security model is to ensure that the programs that a user runs have no more access to objects than the user does. That is, if a user is granted only read access to a file, then when he or she runs a program, that program cannot write to the file. The program, like the user, is granted only read permission.
A subject is the combination of the user's access token plus the program acting on the user's behalf. Windows NT uses subjects to track and manage permissions for the programs each user runs.
When a program or process runs on the user's behalf, it is said to be running in the security context of that user. The security context controls what access the subject has to objects or system services.
To accommodate the client-server model of Windows NT, there are two classes of subjects within the Windows NT security architecture:
In general, when a subject calls an object service through a protected subsystem, the subject's token is used within the service to determine who made the call and to decide whether the caller has sufficient access authority to perform the requested action.
Windows NT allows one process to take on the security attributes of another through a technique called impersonation. For example, a server process typically impersonates a client process to complete a task involving objects to which the server does not normally have access.
In the scenario shown in Figure 2.5, a client is accessing an object on a Windows NT server.
Figure 2.4 Server Subject Security Context
The first thread in the process is a control thread. It is waiting to receive RPC calls via a named pipe. This thread is not impersonating another process, so any access validation to which Thread 1 is subjected will be carried out against the process's primary token.
The second thread in the process is currently handling a call from a client. This thread handles the client's call by temporarily using the client's access token to run with that client's access permissions (that is, the client's security context). While impersonating the client, any access validation to which Thread 2 is subjected is carried out in the security context of the client.
The third thread in this scenario is an idle worker thread that is not impersonating any other process.
The following illustration shows an audited event in which impersonation was used. (Use the Event Viewer to see this type of information for your system.) Here, information for both the primary user and client user is recorded in the security log.
