(I wrote this article almost a year back – when I got a beta version of Vista to play with. So, beware some of it might have changed)
Most rootkits, keyloggers and some spyware install on Windows using features which require administrator rights. Therefore, it would be much safer for users if they run without administrator rights. But the problem is that even now, it is quite difficult to find applications that can run properly with standard user rights. Most of the applications written today assume that the user has administrator rights.
A new security feature in vista is User Account Protection (UAP). The primary goal of this feature is to prevent users from unnecessarily running applications with administrator rights, thereby preventing inadvertent damage to their machine.
UAP is an intermediate step towards the goal of running all programs with standard user rights. Though this is the ideal case, today, most of the applications are written assuming administrator rights. As a result, users are forced to run as administrators. In fact, the first users that the windows setup program lets you create are members of the administrators group. This is where UAP is useful. It runs administrators as standard users by default.
UAP provides several configuration options, including the following:
1. By default, UAP runs all apps as standard user. This can be turned off – in which case all users will run with their full privileges. Interactive applications that request elevation of privileges can be optionally checked for a valid signature.
2. When an app tries to run as administrator, UAP can be configured to ask for the user’s credentials, answer a consent dialog, or silently allow the operation (only if it has the required privileges).
3. Users can mark their applications as requiring administrative privileges by using the app compatibility database or the application manifest. They can also explicitly run an app as the administrator from the right click context menu.
4. For legacy apps that run as standard user but still try to write to %Program Files%
%Windows%, or HKLM\Software\
there is a redirection mechanism which will trap registry and file system write failures and redirect the write to HKU\<SID>\Software\Classes\VirtualStore
and
C:\Users\<name>\AppData\Local\VirtualStore\ respectively.
On windows, every process has a security token which represents the user’s permission. UAP reduces the power of the token in the following ways:
- The administrators SID (Security Identifier) is changed into a deny-only SID.
- The token is deprived of all privileges.
- Depending on the trust level of the program (also known as Mandatory Integrity Control or MIC), one or more group SIDs are added to the token.
Before we look into the above items in detail, let us go over some of the terminology used in windows security.
Access Control Entry (ACE)
ACEs are associated with resources like files and registry entries. They dictate what kind of access a trustee has on the resource. An ACE contains three things – the SID for which it specifies the permission, a bitmask denoting the permissions, and a bit specifying whether to allow or deny permission.
Deny Only SID
When you change an SID to a deny-only SID, the SID will never be used to gain access to a resource. The SID is still kept in the token to make sure that it is used to deny access to resources that explicitly deny access to that trustee. In other words, the deny-only SID is never checked against an allow-ACE of a resource.
Privileges
Privileges are used to control the user’s global rights. In other words, they are not tied to any particular resource and apply to the computer in general. SeDebugPrivilege is an example of a privilege. It lets users debug (look inside) other processes.
Mandatory Integrity Control (MIC)
MIC is a means of restricting access to resources based on the trustworthiness of the application. It is implemented in Vista using restricted SIDs – which permits resources to allow access not only based on the user but also the trustworthiness of the process.
Now let us discuss the implications of the restrictions imposed on apps that are run as standard users.
When the Administrators group SID is turned into a deny-only SID, the process can no longer use its administrator’s group membership to gain access to a resource. This means that the process needs to prove its rights over the resource using a different SID. A process cannot revert to its deny-only SIDs.
In the second step, UAP strips the process token of all privileges other than SeChangeNotifyPrivilege. SeChangeNotifyPrivilege lets the OS bypass checking permission on every file while traversing directories – which is required for fast traversal of directories.
Finally, UAP adds two new group SIDs to the token. These new group SIDs depend on the MIC of the application (which we will get to shortly). Both the new SIDs are in fact the same except for their attributes. The first one has GroupIntegrity and GroupIntegrityEnabled attributes while the second one has GroupIntegrity and GroupIntegrityEnabledDesktop.
Applications in the current vista beta (Build 5303) are categorized into 7 different groups – Secure Process, UI Access, System, High, Medium, Low, and Untrusted. System is the most trustworthy group and Untrusted – the least. Depending on the group, the process is marked with the following MIC labels (they are actually group SIDs in the process access token).
-
Secure Process – Mandatory Label\Secure Process Mandatory Level – S-1-16-20480.
This indicates the highest trust level. There is no information from Microsoft yet on the resources that this level can access.
-
Medium – Mandatory Label\Medium Mandatory Level – S-1-16-8192.
Processes at this level can create and modify files in the user-specific areas of the system. The default label for processes is Mandatory Label\Medium Mandatory Level. All files and registry keys in Vista have a default MIC label of Medium.
-
Low – Mandatory Label\Low Mandatory Level – S-1-16-4096.
These processes are deemed untrustworthy. They can only access very limited sets of resources on the system like the “Temporary Internet Files” directory.
IE 7 in protected mode, for example, runs with the Low MIC label and as a result, has access to only to the “”C:\Users\<username>\AppData\Local\Microsoft\Windows\Temporary Internet Files\Low” folder which also has the MIC label set to Low.
In addition to the segregation of resources, applications with a lower MIC are prevented from opening the handle to processes with a higher MIC. This mitigates several problems including injection of code into the higher privilege process.
Resources created by an app will get the app’s MIC label.
Any child process started by a process will run with the MIC label of its parent. This is normal since the process token is inherited from its parent.
So far we saw how MIC is used to group applications according to their trustworthiness. This was possible by using the new group SIDs in the applications’ access token. Note that this mechanism is possible only while protecting securable objects (objects that have an associated security descriptor).
What about objects that are not securable? Things like windows on the same desktop? To address this problem, Vista has another new feature called User Interface Privilege Isolation (UIPI).
UIPI uses MIC to protect apps from one another. Apps with a lower MIC cannot perform the following operations on apps with higher MIC.
- Cannot start a DDE (Dynamic Data Exchange) conversation.
- Cannot insert keyboard or mouse input into the input stream.
- Cannot hook into (inject DLL).
To conclude, I think that UAP is a good compromise between no users having the administrative privileges vs. all users running as administrators.
