Process Isolation
An important hidden UAC feature that also significantly reduces the Vista attack surface is User Interface Privilege Isolation. UIPI provides process isolation by ensuring that processes running in the security context of a limited-account user can't interfere with processes running in the security context of a privileged-account user.
UIPI protects against shatter attacks, during which malicious mobile code (e.g., worms, viruses, Trojan horses) running in the security context of a limited-account user leverages the Windows interprocess messaging system to inject malicious code into a process that runs in the security context of a privileged-account user. In previous Windows versions, shatter attacks are possible because any process can send a message to any other process running on the same desktop (Windows doesn't provide source authentication for interprocess messages) and because, too often, applications are written to run in the security context of privileged-account users. For more information about UAC process isolation and UIPI, see the Microsoft article "Developer Best Practices and Guidelines for Applications in a Least Privileged Environment" (http://msdn.microsoft.com/windowsvista/default.aspx?pull=/library/en-us/dnlong/html/accprotvista.asp).
Applications and UAC
So far, I've discussed only users and administrators, and how UAC affects them. But not only certain user and administrator actions require administrative privileges; certain applications also require higher privileges to function properly. Vista supports several mechanisms that mark an application as requiring runtime administrative privileges:
- Based on a given application's properties, Vista automatically classifies certain applications as requiring runtime administrative privileges. For example, setup or installation applications are automatically marked as requiring administrative privileges.
- During application development, a developer can mark an application as requiring runtime administrative privileges. He or she does so in the application's manifest file. For a complete set of developer guidelines for building UAC-compliant applications, see "Developer Best Practices and Guidelines for Applications in a Least Privileged Environment."
- An administrator can install an application-compatibility shim on a Vista machine that marks an application as requiring runtime administrative privileges. With this approach, an administrator can let a legacy application start with administrative privileges without making code changes. To learn more about installing an application-compatibility shim, see the Microsoft article "Understanding and Configuring User Account Control in Windows Vista Beta 2" (http://www.microsoft.com/technet/windowsvista/deploy/appcompat/acshims.mspx). To test your legacy applications for privilege concerns, Microsoft provides a new version of the Application Verifier tool. You can download Application Verifier 3.2 from http://www.microsoft.com/downloads/details.aspx?FamilyID=bd02c19c-1250-433c-8c1b-2619bd93b3a2
Applications that require administrator-level privileges are marked with the shield symbol, on top of their standard application icon in the Vista interface, as Figure 6 shows.
Independently of whether an application is marked as requiring runtime administrator-level privileges, users can request to start an application in the security context of an administrator account. Figure 7 shows how users can request that Vista start a program in the security context of a privileged account a single time by selecting Run as administrator in the program's context menu. (This menu appears when you right-click the program icon.)
Users can also configure an application to always run with administrative privileges: Simply select the Run this program as an administrator check box on the Compatibility tab of the application's Properties, as Figure 8 shows. Both limited-account and privileged-account users can access these options. Note that selecting Run this program as an administrator doesn't change Vista's AAM behavior: The system will still prompt limited-account users for administrative credentials and privileged-account users for consent.
File System and Registry Virtualization
Vista can deal transparently with applications that aren't marked as requiring runtime administrator privileges and that must write to a registry or file system location that requires administrator-level access privileges. This functionality is possible thanks to the UAC's file-system and registry virtualization features. UAC will transparently create the data an application requires in a file system or registry location that's accessible by using limited-account user privileges. UAC virtualization also automatically redirects applications to the virtual locations when applications must retrieve or write data.
- For registry virtualization, UAC uses the HKEY_USERS\User_SID_Classes\VirtualStore registry container. Registry virtualization works only for applications that attempt to access the HKEY_LOCAL_MACHINE\SOFTWARE registry container.
- For file-system virtualization, UAC uses the %localappdata%\ virtualstore file system folder. File-system virtualization works only for applications that attempt to access the \%systemroot% or \%programfiles% file-system folders.
UAC virtualization should be considered neither the final nor the ultimate solution for resolving legacy application UAC compatibility issues. Some applications simply might not tolerate virtualization and could stop working properly on Vista. Also, we can't assume that Microsoft will include UAC virtualization support in future OS versions. These are two important arguments for motivating your application developers to make their applications function correctly in the security context of limited user accounts or to mark certain applications as requiring administrator privileges.
Big Change!
Clearly, UAC's least-privilege feature will have a big impact on all Vista users: simple users, administrators, and even application developers. UAC is another Windows feature that promises to provide more proactive out-of-the-box security—similar, for example, to Windows Firewall, which is enabled by default in Windows XP Service Pack 2 (SP2) and later. The net effect of UAC is that users will have to make fewer efforts to run Windows securely. The same can't be said, however, for administrators and developers. Features such as AAM might lead privileged-account users to credential fatigue. In Vista, a lot of responsibility definitely lands on developers' shoulders: They need to ensure that both new and legacy applications run properly and behave correctly on Vista.
End of Article
Prev. page
1
[2]
next page -->
