In continuing our series on upcoming changes in Vista, this article touches on a new change in Windows Security known as Limited User Access or User Access Control (UAC).
Limited User Access
One of the biggest changes coming in Vista is the emphasis on limiting the ability of the user to unknowingly allow viruses and malicious software to infect their computer. Currently this is a large problem since most home users are also the administrator of their computer, which gives them the rights and permissions to do anything they want on their machine by default. This also allows any software that is downloaded to use the rights of the user who is logged on to install software that can harm the machine. To counteract this issue Vista implements an approach known as Limited User Account (LUA) that deals with the least-privileged user account or User Account Control (UAC). This concept is a part of the Department of Defense Trusted Computer System Evaluation Criteria (DOD-5200.28-STD), also known as the Orange Book, which is the accepted standard for computer security. This standard defines least privileged as a principal that "requires that each subject in a system be granted the most restrictive set of privileges (or lowest clearance) needed for the performance of authorized tasks. The application of this principal limits the damage that can result from accident, error, or unauthorized use."
The main goal of LUA is to deliver a more secure desktop by reducing the exposure and attack surface of the O/S by requiring that all users run in standard user mode and by limiting administrator-level access to authorized processes. With LUA in place, administrators can run most applications with a limited privilege, but have the potential to grant additional privileges for specific administrative tasks and functions. In addition, when the user invokes a system task that requires administrator privileges, Vista will notify the user and require administrative authorization before allowing the user to proceed. This prompt for authorization not only ensures that the users do not accidentally modify their desktops, but it also keeps malicious software from invoking administrator privileges without the user's knowledge.
This all sounds very restrictive - I mean, it is my machine after all! I should be able to do anything I want. Well, that is true. However, do you also want the ability to inadvertently install viruses or malware? You should understand that LUA users can still carry out tasks that allow them to complete tasks such as:
Attach to a wireless network
Install a signed PnP driver
Download and install updates
Create and establish VPN and dialup connections
Run most applications
All LUA does is work with the user to limit the users' ability to make changes that could destabilize their computers or inadvertently expose the company network to viruses and malware.
In Vista the preferred group for newly created accounts will be "Users", as opposed to the current method of adding new users to the "Administrators" group. Users will be encouraged to always run in a LUA account in order to protect their machine from the installation of malicious software. The justification for adding new users to the "Administrators" group centers around giving users complete control of their machine so they can install software (whether good or malicious) or hardware at any time. Unfortunately, a lot of developers got lazy and assumed all users of their software would run as administrator. LUA changes all that.
So what does this mean for you? Well, it means a nonadministrative user will not be able to install your product if it requires administrative rights. Microsoft says this restriction typically comes from coding errors or poor implementation of programming and security guidelines. Furthermore, they state that if you follow Microsoft programming recommendations, the installation program should not experience issues with security restrictions.
But let's face it - sometimes there are legitimate reasons for needing administrative rights. So how will users get them? There are two options: 1) you can tell the user to install your product from an account that has the necessary privileges; or 2) your install should prompt the user (CredUIPromptForCredentials) for the credentials (Consent UI) of an account that holds the appropriate privileges needed for installation and to perform the operations using the input credentials.
If your product is installing a driver, then here are the issues you will have to think about:
Drivers have to be signed for x64 platforms.
If you are not an administrator you may not be able to install certain types of devices.
If your driver is a manual start driver, then the user must have the necessary privileges to start and stop your driver.
Access to Registry Data.
Access to Files and Directories.
Access to Shared Resources.
Access to Manageable Data.
Drivers Must Be Signed on x64 Platforms
Beginning with Vista, users will not be able to install unsigned device drivers on x64 platforms. To make a long story short, signing is a way for Windows to know whether a legitimate publisher has provided the software package. The NT Insider articles ("Take Two - x64 Driver Signing" and "Just Sign Everything - What to Sign and How to Sign It for Vista") provide details on driver signing in Vista.
Need Privileges to Install Some Devices
In some cases it appears you need to have administrator privileges to install some devices. To test this we ran as an LUA user and plugged in a USB mass storage device. In this instance Vista loaded the drivers without asking about privileges and our device was available for use. In our next test we plugged in the OSR USB FX2 Learning Kit device and, surprisingly, Figure 1 shows the result.
Figure 1 - LUA at Work
Need Privileges to Start and Stop a Driver
If your driver is a manual start driver, then you might have an issue when starting and stopping your driver. If you have a user-mode application that programmatically starts and stops a driver, then a LUA user will not have the necessary privileges to perform these actions. This means you will either have to prompt the user for the credentials of an account that holds the appropriate privileges, or your driver should automatically be started by the system during one of the boot phases.
Access to Registry Data
If you have applications that modify registry data in protected hives like HKEY_LOCAL_MACHINE, then another potential issue to your project is access to registry data. If your product stores users' data in the registry locations that a non-administrative account cannot access, then you have a problem. For example, it is a better practice to save user runtime settings under HKEY_CURRENT_USER than under HKEY_LOCAL_MACHINE because this part of the registry tree is read-only to LUA users. It is important to note that Vista will provide support for legacy applications on x86 platforms, where writes to HKLM\Software will be redirected to HKCU.
Access to Files and Directories
If you have applications that store information in files or directories that are protected (i.e. C:\Windows or C:\Program Files), then another potential issue to your project is access to data on the disk. If your product stores users' data in file system locations that a non-administrative account cannot access, then you have a problem. It is important to know that Vista will provide support for legacy applications on x86 platforms, while writes to system directories will be redirected to a per-user store.
Access to Shared Resources
If your product shares resources like events, semaphores, or memory, then you need to ensure that all users of the resource have the necessary access privileges. In Vista, a change has been made whereby all services and User Mode Driver Framework (UMDF) drivers will run in a different noninteractive logon session (Session 0) than the first user that logs in. Separating the services into their own non-interactive session mitigates security risks because the services are no longer running in the same session as the users' applications. This change will protect shared resources from attacks that originate in application code. A future edition of The NT Insider will include an article that focuses on the impact of Session 0 isolation on services and drivers.
Access to Manageable Data
I don't know about you, but sometimes I have to create applications or control panel applets that display data to the user of my product. Some of the data presented may be settable by all users and some may only be settable and or visible by administrators. In Vista this matters because it means when you develop UIs, you will have to be aware of what privilege level you are running at to ensure you only display the data appropriate for the viewer of the UI.
If you are not already using security to protect data visible to the user-mode, then you should consider using the Windows Management Interface (WMI). WMI gives you the ability to protect each WMI class you create with a separate security descriptor (using Security Descriptor Definition Language (SDDL). This ensures that only users with the correct rights are allowed to view and/or manipulate the data.
Run as Administrator
One option that Vista offers the user is the ability to run an application as an administrator. When you right-click an application, Explorer displays a menu that contains the option Run as administrator. When this option is selected, a Windows Security dialog appears that allows you to enter the user name and password of an administrator group account under which you want to run the application. The application will have the rights of the logged in account for the life of that application's execution.
While you may think that LUA is only a worry for user-mode developers, it has a lot of impact on driver writers, especially those driver writers who interact with users or services that use shared resources, files, or the registry. This article outlines the areas you will need to explore to get ready for Vista. Remember, Vista is still under development, so I encourage you to keep up with its progress from now until RTM.
By the Way...
One thing to remember is something Hector pointed out in his memorandum titled "Look Out for Vista - Testing Drivers on 5308". Specifically, Hector explained how difficult it is to login as administrator if you are not logged into a domain. If you are like Hector and me, all you ever use on your test machine is the administrator account, so you will want to fix this on your test machine. For the complete rundown on how to do this, checkout the article titled "Jerry's Incoherent Babbling".