What becomes of all my earlier non-admin tips, tricks and recommendations vis-à-vis RunAs, MakeMeAdmin, PrivBar and their interactions with IE and Explorer? The short answer is that Vista changes just about everything with respect to running with least privilege.
Windows Vista makes running as a standard user (non-admin) much more pleasant, feasible and secure than it was on XP. I'm not going to drill into all those improvements here. Instead, the focus of this post is to update my earlier posts about running on XP as a standard user (the "Running as Admin Only When Required" posts in the Table of Contents) as they pertain to Windows Vista. To save some space, I'll assume you've spent at least a little time running Vista.
MakeMeAdmin
Let's start with MakeMeAdmin. Vista renders MakeMeAdmin obsolete. On XP/2003, MakeMeAdmin lets you run as a standard user, and temporarily elevate your standard account to run a selected program with administrative privileges. Vista gives you the same ability, but with more convenience and more safety than MakeMeAdmin could provide.
If you are a member of the Administrators group on Vista, it's effectively the same as being a standard user, as long as you never run anything elevated: all your admin rights and privileges are disabled. Elevating an application does essentially the same thing that MakeMeAdmin did, but more conveniently, and more securely. Here's why:
- The convenience is that by default it's a simple one-click confirmation in a "consent" dialog, rather than having to enter two passwords in two console windows.
- Elevating an application using "consent" requires non-spoofable user interaction. By non-spoofable, I mean that malware with normal user privileges can make a UI look like the consent prompt, but it can't elevate anything. Further, the consent prompt appears on the secure "winlogon" desktop, which cannot be seen or manipulated by unprivileged code. Even if low-privileged malware steals your password, it can't get anything to run elevated without the interactive user going through the elevation UI. On XP, malware that obtained the password for an admin account could run programs with full admin privileges at any time.
- "Elevated" applications on Windows XP running on the same desktop with lower-privileged programs were subject to "shatter attacks" – the lower-privileged programs sending window messages to the windows of higher-privileged applications and driving them programmatically, or exploiting buffer overflows to run arbitrary code in the "elevated" context. With Windows Vista's Mandatory Integrity Control (MIC) and User Interface Privilege Isolation (UIPI), this becomes more difficult. (See Mark Russinovich's recent TechNet Magazine article for more information.)
You have to be careful about what you choose to elevate, but the same was true with MakeMeAdmin, too.
RunAs
Windows XP provided two interfaces for "RunAs" – the "right-click" dialog version, and the runas.exe console application. The dialog version has been replaced by the "Run as administrator" option. The console utility is still there, but it has limitations.
The Windows Shell team probably knows for sure, but I'm willing to guess that the main reason people used the "Run As" dialog on XP (probably only a tiny percentage ever used it anyway) was to run a program with admin permissions, and that for this purpose, "Run as administrator" serves as a superior substitute. With the default settings, a member of Administrators can use it as a MakeMeAdmin replacement (see above); a standard user gets a dialog that lets them enter the credentials of any admin account and run the target program with those credentials, also gaining the security improvements of UIPI as well as the secure desktop UI. One complaint I have seen in my blog's comments is that a member of Administrators can't choose to run as a different admin user, such as a Domain Admin account. This can be addressed by changing the elevation behavior for administrators from "prompt for consent" to "prompt for credentials".
The runas.exe console utility still exists, and it will let you run a program as a different user, but not with elevated permissions. If you specify an admin account, for example, you get the "filtered token" for that account, with admin groups and privileges disabled. As mentioned earlier, you'd need to go through the elevation UI to get the "full token".
Runas.exe is not as secure as the elevation UI. Runas.exe runs and collects credentials in the security context of the logged-on user, and so any malware running as that user can take control of that process, monitor the keystrokes going into it, changing the target program, etc. By contrast, the elevation UI collects credentials on the secure "winlogon" desktop (by default), which is accessible only to code running as System.
One thing that hasn't changed with runas.exe is that it still requires credential entry at the keyboard – you can't pipe in a password through stdin or in the command line. This is to help discourage the insecure practice of putting plain-text passwords in script files. (Answering one of the most commonly-asked questions in my blog's comments.)
Browsing the file system with Internet Explorer, and running IE and Windows Explorer as a different user
Internet Explorer used to be able to browse the file system. Beginning with IE7, that became history, both on XP and Vista. If you enter a file system path into the IE7 address bar, it will open a new Windows Explorer window to that path. From a security perspective, it seems like a pretty good idea not to allow the main program that interacts with that hostile world known as the Internet to also interact with your file system in the same way.
This change broke scenarios for a number of people who had found IE to be more "RunAs-friendly" than Windows Explorer for browsing the file system with elevated privileges. Windows Explorer on XP can be made more RunAs-friendly – see the SeparateProcess advice I posted here.
On Vista, however, there are more changes. Neither Internet Explorer nor Windows Explorer is willing to entertain multiple accounts on the same desktop. If you try to run IE under a different user account from that of the desktop, it will display an error message: "The RUNAS command is not supported." As I understand it, the primary reason is that with Protected Mode Internet Explorer, which runs at Low Integrity Level, IE also launches a Medium IL broker process (ieuser.exe) which runs as the desktop user and which gates selected Medium IL operations for the Low IL process. Allowing multiple identities into that mix would have introduced significant complexity best avoided. If you try to run Windows Explorer as a different user, you'll see nothing – the new process starts but exits without displaying a window.
However, I have found that it is possible for a member of the Administrators group to run both IE and Explorer with elevated privileges. With IE, right-click its icon in the QuickLaunch or in the All Programs menu (not at the top of the Start Menu) and choose "Run as administrator". One thing you'll (hopefully) notice is that the UAC elevation prompt for Internet Explorer shows it as "an unidentified program" from an "unidentified publisher", rather than as a Windows component or other signed program from a trusted publisher. As I understand it, the reason for this is because systems will quite often have IE plug-ins that are not signed and which may introduce more risk than the user may be aware of. Hence, the "unsigned" prompt is intended to discourage running IE with full admin privileges.
Explorer is a little trickier. Directly applying "Run as administrator" won't do it, but running it from an elevated command shell often will. I find that a command line like "explorer /e,c:\" will work, while just running "explorer" might not. But as before: if it works at all, it is an unintentional side effect of the current implementation, and is subject to change at any time.
How can you tell whether it worked? PrivBar still works on Vista, both for Internet Explorer and Windows Explorer.
