Misconceptions about Least Privilege

I found a trackback to my recent post wishing for 2005 to be the Year of Least Privilege, and unfortunately, the response repeats one of the major misconceptions of Least Privilege user accounts:

G. Andrew Duthie asks: "Will 2005 be the year of Least Privilege" (via Robert Scoble).

Not a chance.  Why not?  Scoble sums it up pretty well (unintentionally):

For those who don't know what Least Privilege is, it means turning off a bunch of administrator rights so that no software can install without logging off and logging back in as administrator

People don't want to have to log off and log back on to get stuff installed!  That's awful.  People want to use their computer and have it get out of the way.  What should happen is that they are prompted for an administrator login when admin privileges are needed and it should all just work seamlessly once such a login has been provided.  Similarly, if they are logged in as Administrator, they should have to provide their password to install software anyway so that they know it's happening.

Essentially, don't let software install and run unsafe code without first confirming the user trusts it.  Check out sudo for how to do it on the command line and OS X for how to put a GUI on it.  Then while you're at it - disable the administrator account and just use this system instead (see sudo for how to handle permissions when there is no administrator/root account).

Unfortunately, the author of this post is incorrect in the assertion (also made, unfortunately, by Scoble) that one has to log off and log back on to change from low-privilege user to admin. You can log in / log out, using Fast User Switching in Windows XP (Home, or Pro, if the machine is not joined to a domain), and using FUS is fast, easy, and provides isolation of applications, while still allowing you to keep your apps running when you switch back and forth. But if you can't use FUS, you don't have to log out and log back in. You can use RunAs to run apps, MMC utilities, etc. with your admin account, or you can use Aaron Margosis' MakeMeAdmin utility (a simple batch file for creating an admin command prompt that uses your existing user profile) to run apps from the command-line.

Additionally, I've used OS X (I bought an iMac for my wife specifically for the purpose of better understanding how least privilege works in OS X), and while I would tend to agree that the user experience is good in this area of OS X, what the comments don't take into account is that with that kind of interface the danger is that someone will attempt (probably successfully) to spoof the UI such that an unsuspecting user will enter their admin credentials not realizing that it's not actually the OS prompting them. The more often that a user's work is interrupted by this type of prompt, the greater the likelihood that they will be accustomed to simply entering the credentials without thought so they can get on with what they really want to accomplish (interestingly enough, the post above notes this..."want to use their computer and have it get out of the way" but then goes on to suggest interrupting them with dialogs that they won't care about, apart from getting beyond them as quickly as possible). Not meant as a criticism of OS X by any means, but as an observation on what users want to do, which is get to the functionality that they want, not spend time filling out credential dialogs.

I'm certainly eager to see what the LUA user experience will be in Longhorn, and I'm hopeful that it will be improved over what exists in Windows XP. But it's not only possible, but relatively easy to run as a low-privileged user in XP and Windows Server 2003 (and Windows 2000, for that matter), and it doesn't require a great deal of expertise (see Aaron's blog for his experiences in setting up non-tech savvy relatives with LUA accounts).

What do you think? Have you tried running as a non-admin? Did you find challenges? Did you give up? Let me know in the comments...


Comments (5)
  1. Youre going to need a way to prevent the spoofing of any quick privilenge change dialogs that will prompt for passwords.

    A quick suggestion – make the NumLock, CapsLock and ScrollLock lights on the keyboard blink (either in unison or in sequence) when a ‘secure’ dialog has the focus.

    Presumably the OS will restrict programmatic input to these dialogs, as well as restricting the ability for other processes to observe keystrokes going to these dialogs. Shouldnt be too hard for the OS to intercept the ability of apps to blink the XXXLock lights.

  2. steve perry says:

    what I have found is that there are still not enough programs that install for "everyone" and instead install for the loged in user. This cuases me to have to log in as an admin, elavate my non-admin account to admin, install the app, then remove the admin privalage.

  3. Jonathan says:

    Been running as non-admin for about 2 years now. Hardest challenge is of course with old apps that assume everyone’s an admin. The fact that I use XP Home at home doesn’t make it very easy to diagnose and fix these issues–auditing is not available on XP Home so I can’t see where things are failing, and the lack of the Security tab (except in Safe Mode) makes it hard to change permissions (thank goodness for Cacls.exe).

  4. Damien,

    Interesting idea on the lights, but I’m not sure how practical it is. Given that users are very good at ignoring dialogs, it’s probably safe to assume that they would be exceedingly unlikely to pay attention to the presence or absence of lights on the keyboard (particularly if they’re touch typists…I’m not trained as such, but rarely look at the keyboard anymore from simple practice). Unfortunately, I don’t think there are any silver bullets for absolutely ensuring that some security dialog can’t/won’t be spoofed, at least not so long as users remain less invested in security than they are in getting to where they want to be. I’m certainly open to any "foolproof" suggestions, though.


    Your situation is exactly what Aaron Margosis’ MakeMeAdmin utility (http://blogs.msdn.com/aaron_margosis/archive/2004/07/24/193721.aspx) is designed for. It uses RunAs twice, once to set up a command-line with admin privileges, which adds your account to the admins group, then again to open a second command-line, this one with your regular account (now carrying the admin token), and then removing your account from the admin group before closing the first window. You’re left with a command-line window that has admin rights, but uses your LUA profile, so any software installer you kick off from this window will install for the correct user. Works great.


    Agreed that legacy apps can be one of the biggest challenges with LUA. One of the reasons I strongly encourage developers to stop running as admin is in hopes of not continuing to have this problem in new apps as well as old.

  5. Damien,

    Except for the SAS (secure attention sequence, or control-alt-del), any visual feedback using the keyboard lights can be spoofed unfortunately 🙁

Comments are closed.

Skip to main content