This article originally appeared in c't 10/07, p. 180
Rights and integrity
Security architecture of Windows Vista, Part 1
With Windows vista, Microsoft has added yet another protection mechanism to the already pretty complex security model of its NT line. This sets up a high security zone for the system and segregates suspect elements from the legitimate occupants.
The mainstay of a secure operating system is access protection - the undesirable activities of malware (from the internet etc.) can only be blocked by preventing a free-for-all. With the user account control of Windows Vista, Microsoft is attempting to make it more palatable for the user to work with restricted rights. But even the rights of a normal user go too far if malware takes hold, since it can read, change or delete all the documents in the name of the user.
Programs which could be targeted by attacks from the internet therefore need to be further restricted to increase security. The Windows XP security model theoretically offers a wealth of features for this purpose. However, Microsoft has taken a different approach and provided Vista with another mechanism which is placed in front of the previous security model - Mandatory Integrity Control.
In order to understand the reasons for this approach and the new features, it is worth taking a look at the security model of Windows XP which has been there in principle since Windows NT. This model monitors a large number of objects in the system - files, registry keys, processes, threads, pipes and quite a few more.
The players in the system are the processes and threads. Each process has an access token which determines what it is allowed to do. The token contains the name of the user (in whose name the process is operating) in the form of a security ID (SID). SIDs are numbers of variable length which the system uses internally instead of using names in human-readable text. When a new user account is created, it acquires a (probably) globally unique SID, which then stays behind when the user name is subsequently changed - this is important for segregating users on a network.
The access token also contains a list of group associations (also in the form of SIDs) and a set of privileges. Privileges are access rights of a general nature which are not linked to a particular object, such as permissions to shut down the computer or load drivers.
Under Vista, the command line command whoami /all shows some of the information from the access token of the invoker (strictly speaking, from his own access token). For Windows XP, Microsoft provides the program as a component of the free support tools (you can use the provided link to download all the software mentioned in this article). Mark Russinovich's Process Explorer is a convenient tool for examining access tokens and the other things described in the following. It lists the processes running on the system and provides detailed information under the Properties menu item when the right mouse button is pressed. The data from the access token can be found under the Security tab.
The second important data structure for security is the Security Descriptor. Each object that is subject to access control on the system has a Security Descriptor which determines who can do what with the object. The most important components of this are the owner's SID and a list containing access rights - the Discretionary Access Control List (DACL). The DACL is made up of a series of entries which either allow or deny a security ID certain rights in each case.
If a process wants to access an object, Windows goes through the DACL in the security descriptor of the object, entry by entry, and compares the SIDs listed there with those stored in the access token of the process. As soon as it finds a deny rule for a requested right which matches one of the SIDs in the access token, Windows denies access. If no "allow rule" for the desired right matches after processing the entire list, access is also denied. This simplified presentation may be sufficient for now - more details in .