News

Running as Non-Admin: Threat or Menace?

• By Mike Gunderloy
• January 8, 2004

Microsoft recently added an article to its MSDN Web site: Developing Software in Visual Studio .NET with Non-Administrative Privileges. Written by Lars Bergstrom from the Visual Studio .NET team, the article argues that the way to minimize the potential damage from security issues is to log on to your computer as a user who's not a member of the local administrators group. For users to be able to do this, of course, the software that they use every day must work properly for non-administrative users. Thus, he argues, developers must log in, develop, and test applications as non-admin users. "There is no excuse not to do it," he boldly claims.

Of course, this is hardly the first article to promote this notion that developers should work as non-admins. It's an idea that's been going around the Visual Studio .NET community for a couple of years now, and I'm sure it's surfaced elsewhere as well. This article is the most thorough examination of the consequences of this decision that I've seen, though; it's 14 printed pages of hacks, workarounds, and commands that you'll need to use when you run up against parts of Windows and .NET that weren't designed for non-admin use. Most of these amount to ways to temporarily gain administrative privileges for particular actions.

Though the idea of running as a non-admin is seductive at first glance ("sure, I care about security, so I'll take the plunge"), I don't think it really stands up to careful analysis. Let's look at the two stated reasons in turn: providing a more robust security environment on your machine, and delivering applications that will work for non-admin users.

As far as a robust environment goes, it's not a simple binary switch (admin bad, non-admin good). There are many other ways to protect your computer from malware than running as a non-admin, and as a developer you (of all people) ought to be able to use them. These include protecting your network with a firewall, not inserting random CDs into your machine if you don't know where they come from, installing a virus scanner (and keeping it up to date), keeping Windows itself patched, and not executing e-mail attachments. This sort of defense in depth can go a long way towards keeping the malware off your machine in the first place. Also, I suspect people working at Microsoft might have a somewhat skewed view of the number of crackers in the world, since they're a prime target. Out here in the relative obscurity of a small company with just a few IP addresses, my chance of a drive-by hacking is somewhat less than that of the average Microsoft employee.

Bear in mind, too, that being a non-admin user at the time that you allow a virus to execute is no guarantee that the virus will only execute as a non-admin user. It's entirely possible that the next clever bit of nasty code to come down the pike will find an elevation of privileges hole in Windows to exploit. So don't let the fact that you're a non-admin user lull you into a false sense of security.

Though reasonable people can disagree about the relative risks of running as a non-admin user, the notion that you need to be a non-admin user to develop software for non-admin users strikes me as just plain bizarre. I have no objection to the idea that you need to test your software as a non-admin user. That's just a small part of the overall notion that your software should be tested in the environment where you expect it to run. You also ought to test with a realistic amount of RAM (rather than the all-that-money-can-buy that you probably have in your development machine), on older versions of Windows, and so on. But you don't see anyone arguing that developers should work on machines with only 128 MB of RAM because that's where there software will run. And we're not asked to replace our monitors with screen readers to ensure that software is accessible to visually impaired users. Everyone would see those notions as absurd, and yet the analogous reason is trotted out in the security arena with a straight face.

So what's going on here? Why do so many otherwise-reasonable developers promote the "run as a non-admin" idea? I'm not able to read their minds, of course, but I wonder whether there's not a bit of developer macho going on here. Just as some developers look down on those who use the mouse because their own hands never leave the keyboard, others who have taken the time to master the difficulties of non-admin use can look down at those who haven't or won't. "Only wimps need to run as Administrator," I can almost hear them saying.

But running as a non-admin isn't free. Remember those fourteen pages of workarounds? It takes time to learn those things, time to reconfigure your working environment, time and money to find tools to replace the ones you're used to that non longer work in this non-admin world. For my part, I choose to make my development environment as productive as it can possibly be. So far, that works out to being aware of security issues, while still running as an admin user.