This article originally appeared in c't 10/07, P. 180
Rights and integrity
Security architecture of Windows Vista, Part 2
By default only Internet Explorer uses the new integrity levels under Vista. Using preinstalled tools, the integrity levels can also be applied to other programs to make the system even more secure.
Part 1 did not cover how processes generally acquire their permissions and integrity levels. According to the Windows security model, which is known from Vista predecessors, a child process normally inherits the access token of its parent. Vista adds one bit to this process in the access token, TOKEN_MANDATORY_POLICY_NEW_PROCESS_MIN, which is set for normal users but which is cleared in administrator tokens. The effect is that new processes acquire an integrity level which is the lesser of that of the generated process and that of the file which contains the executable code. A normal user is therefore unable to start any processes with an integrity level which is higher than the integrity level of the exe file.
If malicious code does manage to get through a security hole in Internet Explorer at Low integrity level, then this program can only start at the Low level. Files which IE writes in its folders also inherit the Low integrity level. This protects the user from starting at a higher level by mistake.
In order to test what a process running at Low level like IE is permitted to do, open a prompt with normal user rights and use whoami /all to make sure that the process is running at Medium level. Copy the command interpreter cmd.exe from \Windows\System32 into your LocalLow folder. Using icacls cmd.exe, you can make sure that the file has inherited the integrity level Low - "I" stands for "inherited". Now, when you start cmd.exe, the process acquires the integrity level Low which can be checked using whoami /all.
Make sure that you are prevented from changing even your own files from this Low command line. (In Process Explorer, there is a column which shows the integrity level.)
Unfortunately, Whoami does not show the policy of the access token. However, if you are familiar with programming in C and have access to a compiler and Vista SDK, you can look inside comparatively easily by hacking a couple of lines into the example program Mytoken from the SDK which interrogate the TokenMandatoryPolicy with GetTokenInformation(). There, you will also see the other policy bit TOKEN_MANDATORY_POLICY_NO_WRITE_UP. According to the documentation, this has the effect of not allowing objects with a higher integrity level to be written to with this access token. I have always found this to be set in the access tokens which I have examined.