The Desktop FilesLeaving the Administrator Behind
Wes Miller
More than three years ago, I began the process of taking my user account on my primary Windows system from local administrator account to local user account. I had worked at Microsoft for more than seven years, always running as a fully privileged administrator. Sure, it was convenient—but that scary lack of security
highlights the amazing luck I had (that so many of us have) that running as an administrator every day isn't more caustic to more systems more often.
I often wish that there was a way to get a good statistic on this, but both my gut and the industry tell me that too many organizations—and too many IT pros themselves—are running as local administrators today. At Winternals, when I switched to running as a user, it was with the premise of learning both how hard it was (as a "prosumer") and to get some understanding of how our product, Winternals Protection Manager, could help in an average organization. Given that most organizations were, and still are, running with a good percentage of users as administrators, our goal was to enable administrators to run as users, but to make the transition—or at least the pain points—as minimal as possible. Regardless of the technology you use, it isn't easy to move your organization from one where users are administrators to one where they are users, but it is the single most effective way to reduce the attack surface within your organization. Think of it as an intra-system firewall, because that's really what it is.
How Did We Get Here?
My Challenge to You: Feel the Pain
If you haven't yet begun thinking about moving your administrators to users, you should. And I'd encourage you to start by experimenting with it yourself. Not on a secondary machine—that's cheating. Try it on your primary system, the one you use every day. I'd also encourage you to even try it without using User Account Control (UAC) if you are running Windows Vista®. When you begin evangelizing an effort within your organization to change something, it's a good idea to be a practitioner of it before you preach. I think you'll find that running as non-admin isn't really all that difficult—and that with the added security of doing so, you'll really change your organization's attack surface.
That most users act as administrators is rooted in Windows® history. With the first versions of Windows, before Windows NT® 3.1, every interactive user was as empowered as the next—functionally, there was no security. In the home, this wasn't terrible; it meant that all software installed the same way. The assumption was that the user owned the computer and that all software was installed for all users of that computer.
When Windows NT first appeared, it certainly didn't immediately own the enterprise (let alone the consumer) market. And because of the Win32® compatibility between 32-bit Windows and Windows NT, most application vendors didn't rebuild their applications just for the sake of the security infrastructure of Windows NT. In fact, it really wasn't until Windows 2000 that many consumer-oriented independent software vendor (ISVs) started paying attention to Windows NT. It was Windows XP, of course, that forced the issue as it ended the 9x family of Windows.
But still, applications rolled on, assuming that every user on the system had access to write to Program Files (users don't), and HKEY_LOCAL_MACHINE (HKLM) in the registry (users don't), and HKEY_CLASSES_ROOT (users don't). Games are often among the worst offenders in assuming access; see Matt Clapham's article on this topic at technetmagazine.com/issues/2007/02/Gaming.
This is problematic because most cross-system apps store their files and registry settings in those locations and you need to be able to read and write to those locations in order to be able to install them. Unfortunately, some apps then insist on writing to those keys after installation. For example, my daughter has a game that is Flash-based. It attempts to install a custom player every time you run it—meaning that when my daughter runs as a user, not an administrator, the application fails to start, with a fatal error. While this is extreme, and it is a consumer application, the reality is that many non-consumer applications still don't play well in the world of non-administrative users. In fact, if you follow up on my challenge (see the sidebar, "My Challenge to You: Feel the Pain"), you'll discover just how much Windows itself isn't tolerant of running as a user.
If you take a look at Figure 1, you'll see what running IPConfig /release as a user looks like on Windows XP. If you compare that to Figure 2, you'll see that the same command under Windows Vista is not that much better, but at least you know why the command is failing. Note that the networking tools as a whole have been improved to allow users to refresh their IP addresses. Similarly, trying to run Computer Management (compmgmt.msc) as a user under either version lets you perform a limited number of tasks—but generally results in frustrating dead-ends, as Figure 3 shows. While Windows Vista doesn't initially enable many of the tools in Computer Management, it does present clearer access denied messages.
Figure 1** Running as a user under Windows XP **(Click the image for a larger view)
Figure 2** Running as a user under Windows Vista **(Click the image for a larger view)
Figure 3** Misleading message after running compmgmt.msc as a user on Windows XP **(Click the image for a larger view)
Why It Matters
So why should you care? Because we, as IT professionals, should begin forcing applications to adjust to least-privileged users, instead of vice versa where applications assume the interactive user owns the system.
Unfortunately, the same policies that allow administrators to write to registry keys also grant any malware run in their user context full access to anything they have not been explicitly denied via access control lists (ACLs). In the world of UNIX, people follow the rule regarding not running as root (the functional equivalent of the Windows Administrator account), mostly because the ecosystem of software that pushes the boundaries of the security model is tiny to nonexistent.
Still, the best thing you can do is to follow that same wisdom and only run as an administrator when it is explicitly required—or better yet, only run individual applications as an administrator. By doing so, you raise that intra-system firewall I mentioned earlier. Then, when malware or spyware attempts to do something it shouldn't, it fails—because it can't write to the registry or file system locations it needs in order to really infect your system (such as installing a service or driver, or installing for all users). In addition, doing so allows anti-malware software to contain malware that it recognizes, without risking the entire system first.
Note, however, that users aren't impervious to attack. Though this class of malware doesn't exist widely yet, there is the potential for malware to successfully infect an individual user's context or destroy his data. But the attack vector posed by such software is limited. As a result, the same thing that keeps malware instances low on Linux or the Macintosh (the lower number of potential victims making it a less appealing playground for malware authors) can help ensure the general safety of your end users—and yourself—today.
Wither Power Users?
When we were developing Protection Manager, one of the comments we heard from customers was, "We're running Windows XP with all of our users as power users, not administrators, so we're secure." The reality, though, is that power users are just a few steps away from administrators. There are several potential holes that would, with a little work, allow a power user on Windows XP to become an administrator. In fact, the power users group was eliminated on Windows Vista and Windows Server® 2008; only a system upgraded from an earlier version of Windows will have a power users group. All in all, you should always avoid using the power users group, even if you are using Windows XP.
Lossy Permissions
If you read my March column on Windows thin clients (technetmagazine.com/issues/2008/03/DesktopFiles), you'll recall I spoke against the prospect of thinning out Windows XP to save space. In the same vein, there is a common practice to enable administrators transitioning to users that you will need to consider, but do so carefully. That is the practice of adjusting ACLs on the registry and file system so that users can write to locations they are not normally able to—thus enabling problematic applications.
Obviously, the best choice is to get an updated version of an application that doesn't require such a change, but that's not always possible. If you must change permissions (that is, drop them), proceed very carefully. Remember that the firewall between a user and an administrator is defined largely by registry and file system permissions. Opening them up lowers your protection and potentially widens the attack surface posed by malware—so please proceed judiciously.
What about UAC?
No discussion of transitioning users from administrators to users is complete without addressing User Account Control (UAC) in Windows Vista. UAC, like similar functionality on the Mac OS X, lets you run "as an administrator" without putting yourself at so much risk.
How does this work? Take a look in Figure 4 at what Process Explorer is showing about cmd.exe. The instance of cmd.exe on the right was started without elevation, with me running as an administrator. As a result, even though the user on the right is identical to the one on the left (where the cmd.exe was started with elevation), the application itself does not contain the necessary privileges and tokens for it (and the user running that instance) to perform any tasks that require administrative rights. UAC works by lowering the attack surface within a user's interactive context. The only problem is that something has to tell Windows that this task requires administrative privileges and that the user is OK with allowing the elevation required to complete this task.
Figure 4** Two instances of cmd.exe with different privileges **(Click the image for a larger view)
The small shields in Windows Vista show you which tasks require elevation (see Figure 5). These tasks require elevation every time you run them—and this is one of the sore points the press has chosen to highlight with Windows Vista. The alternative, letting the credentials be more "sticky," poses a potential security threat that could be used to more easily exploit the system.
Figure 5** Shields in Windows Vista indicate the need for elevation **(Click the image for a larger view)
If UAC is enabled and your users are running simply as users, they will be prompted for a set of administrative credentials when an application requires administrative privileges. Note in this case, like when using runas or psexec, that the app runs literally in the context of the user you launched it as, unlike under UAC as an administrator. In that case, the tasks run in your context, but with elevated privileges.
Running Windows Vista as a User?
My personal preference when running Windows Vista is to actually run as a user, not an administrator with UAC, because I believe that in the average enterprise, this is still the best idea. After all, your users have full control over their systems and you may have decreased the window of opportunity for malware.
Moreover, if you are intending to manage your users with Group Policy, anti-virus, anti-malware, or other software and you want central control over whether these tasks actually get enforced or completed, ensuring your end users are not administrators is a critical step. If your users are administrators, they can stop services, add or remove drivers, and more. Of course, a crafty end user running as a user can use Windows PE to bypass some security hurdles. BitLocker® can make that more difficult, but again, remember that end users with physical access can do whatever they want to their machine, given enough time, knowledge, and dedication.
Running Windows Vista as a user isn't all that much different from running Windows XP as a user. I use the same tools—PSExec, RunAs, (and now UAC) to run tasks as an administrator as needed. The nice thing is that quite a few tasks in Windows XP that used to require administrative privileges no longer do. For example, a Windows Vista user can install a local printer. (Network printers could be installed by users in Windows XP, but installing a local printer required administrative privilege.) In Windows Vista, as long as the user is physically at the machine and the printer driver is in the driver store, a user can install a printer and manage print jobs on it (see go.microsoft.com/fwlink/?LinkId=111534 for more information). Note that this functionality is disabled in Windows Server 2008.
Of course, people make fun of the clock functionality (or lack thereof) when running as a user in Windows XP—try double-clicking on the clock as a user (something people often do to see what the date is, whether or not it was designed to work that way)—you get the error shown in Figure 6. Not very friendly. In Windows XP, you can modify policy so that users can do this, but in Windows Vista, it was changed to just work that way. So all in all, running as a user—whether you're using UAC or running as a formal user and elevating as another user, is generally more palatable on Windows Vista than it was on Windows XP.
Figure 6** In Windows XP, non-admins couldn't change the time **(Click the image for a larger view)
Remember the Limits
Remember that moving your users to be non-admins isn't a panacea. Dedicated end users are still physically located on their own PCs, and they can work pretty diligently to exploit their own systems, especially if the policy or user privileges are inconveniencing them or preventing them from getting their work done.
If your users are running as administrators, it doesn't take much work to bypass any Group Policy in place. Of course, with a little more work, users can boot to Windows PE and modify permissions that they wouldn't normally have privileges to—though if you use BitLocker or other drive/volume encryption, you can make that impossible, or at least more difficult.
The most important thing you can do if your organization has not yet begun transitioning end users to run as users is to familiarize yourself with the reasons why you and the organization should spend time, money, and effort to move away from having users running as administrators.
Sure, legacy applications can be hard to let go of, but if you have an application that simply cannot be run as a user, it's just a bad idea to hold on to it at the expense of your organization's security. You should consider virtualizing the application—literally moving it into a Virtual Machine where the user is indeed an administrator. This lets the application be used as needed, but still allows you to secure the rest of the system by moving the administrators to users.
Note that through this entire column, I have not used the word "lockdown" or any derivative of it. Many people consider moving administrators to users a part of a task often described using that word. Perhaps it's my psychology background or my current marketing world, but I think it's important to not use words that make your end users feel like their privileges are being taken away (even though at a semantics level, they are).
Instead, focus on the security benefits to the organization and make sure you have a good plan for edge cases where either a specific user absolutely cannot run as a user or there is a particular task that requires admin privileges. Whether you use something manual like my Run.vbs script (which you'll find at technetmagazine.com/issues/2007/03/DesktopFiles) or use a commercial solution to help you make the transition (that lets you hide the details from your end users and makes things "just work"), it's important to start heading down the non-admin road as soon as you can. Frequent TechNet Magazine contributor Aaron Margosis is the evangelist when it comes to running as a non-administrator. If you aren't familiar with his blog, you should be—it's the best place to go for in-depth information on this topic (see blogs.msdn.com/aaron_margosis).
Wes Miller is currently a Senior Technical Product Manager at CoreTrace (www.CoreTrace.com) in Austin, Texas. Previously, he worked at Winternals Software and as a Program Manager at Microsoft. Wes can be reached at technet@getwired.com.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.