Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

Running Non Admin

Running Non Admin

  • Comments 38

There’s been a fascinating process going on over here behind the curtains.  With the advent of XP SP2, more and more people are running as non administrative users.  Well, it’s my turn to practice what I preach, I’ve taken the plunge on my laptop and my home machine, I’m now running as a non admin user (I can’t do it on my development machine at work for the next few weeks for a variety of reasons).

The process so far has been remarkably pain free, but there have been some “interesting” idiosyncrasies.  First off, I’ve been quite surprised at the number of games that have worked flawlessly.  I was expecting to have major issues, but none so far, with the exception of Asheron’s Call.  Annoyingly, the problem with AC isn’t the game itself, it’s with Microsoft’s Gaming Zone software, which insists on modifying files in the C:\Program Files directory. 

Aaron Margosis’ blog posts about running as a limited user have been extremely helpful as well.

Having said that, there are some oddities I’ve noticed.  First off: There seem to be a lot of applications that “assume” that they know what the user’s going to do.  For instance, if you double click on the time in the system tray, it pops up with “You don’t have the proper privilege level to change the System Time”.  This is a completely accurate statement, since modifying the time requires the SeSystemTime privilege, which isn’t granted to limited users.  But it assumes that the reason that I was clicking on the time was to change the time.  But maybe I wanted to use the date&time control panel as a shortcut to the calendar?  I know of a bunch of users that call action of double clicking on the time in the taskbar as invoking the “cool windows calendar”, they don’t realize that they’re just bringing up the standard date&time applet.  If I don’t have the SeSystemTime privilege, then why not just grey out the “OK” button?  Let me navigate the control but just prevent me from changing things.

Similarly, the users control panel applet prompts you with a request to enter your credentials.  Why?  There are lots of things a limited user can do with the users control panel applet (enumerating groups, enumerating users, enumerating group membership, setting user information).  But the control panel applet ASSUMES that the user wants to manipulate the state of the other users.  It’s certainly true that most of the useful functionality of that control panel applet requires admin access.  But it should have waited until the user attempted to perform an action that was denied before it prompted the user for admin credentials.

From my standpoint, these examples violate two of the principals of designing interfaces that involve security: 

1)      Don’t tell the user they can’t do something until you’ve proven that they can’t do it.

2)      Don’t assume what access rights the user needs to perform an operation. 

The date&time control panel violates the first principal.  The user might be interacting with the control panel for reasons other than changing the time.  It turns out that the reason for this is that the date&time applet violates the principle of least privilege by enabling the SeDateTime privilege, running the control panel applet, and then disabling the privilege.  If the control panel applet had waited until the user clicked on the “Apply” button before it enabled the privilege (and then failed when the enable privilege failed), it would have better served the user IMHO.

The users control panel applet violates the second principal.  In the case of the users control panel, it assumed that I was going to do something that required admin access.   This may in fact be a reasonable assumption given the work that the users control panel applet does (its primary task is to manage local group membership).  But the applet assumes up front that the user has to be an administrator to perform the action.  There may in fact be other classes of users that can access the information in the users control panel – as an example, members of the domains’ “account operators” group may very well be able to perform some or all the actions that the users control panel applet performs.  But the control panel applet doesn’t check for that – it assumes that the user has to be a member of the local administrators group to use the control panel applet.  Interestingly enough, this behavior only happens on XP PRO when joined to a domain.  If you’re not joined to a domain, the users control panel applet allows you to change your user information without prompting you – even as a limited user.   Peter Torr also pointed out that the computer management MCC snapin (compmgmt.msc) does the “right” thing – you can interact with the UI, perform actions (adding users to groups, etc), and it’s only when you click the “Apply” button that it fails.  The snap-in doesn’t know what’s allowed or not, it just tries the operation, and reports the failure to the user.

This is a really tough problem to solve from a UI perspective – you want to allow the user to do their work, but it’s also highly desirable that you not elevate the privilege of the user beyond the minimum that’s required for them to do their job.  The good news is that with more and more developers (both at Microsoft and outside Microsoft) running as non administrative users, more and more of these quirks in the system will be fixed.

 

Edit: Thanks Mike :)
  • How would I debug another Windows Service? I think that I still have to run as admin. Would I not have a problem with a service that I wrote as well as debugging ASP.NET code running in IIS? I seek guidance.

    Wally
  • To debug a running process, you need the SeDebug privilege. And that means that you're effectively an admin. Instead of being a true admin, you could go with Power User, but it's trivial for a power user to elevate their privilege to admin.

    My solution, like that of many other developers, is to have a separate machine for test purposes - I'm an admin on that test machine, but a limited user on my day-to-day machine (but I don't debug on that machine). I also don't do anything other than test on the test machine. I regularly pave over the test machine, and I don't allow any sensitive data to be kept on the test machine - it's a machine whose contents I don't care about.
  • A nice solution to the problem (i.e. two machines). But, do you also test as a limited user, depending on the test? I have been running as a non administrator for awhile, but I also test on other test systems as non administrator until I hit the final wall when I have to move up to administrator level.

    Also, Wally, there is a specific way to debug ASP.NET pages as a non administrator (set the user for the ASP.NET process to a limited user -- it can be encrypted as well rather than listed in open text in machine.config). The good news for ASP.NET is that you will be able to debug as a limited user in ASP.NET 2.0. Good to see this is catching on and tools are being changed accordingly.
  • Robert, I don't test as a limited user, unless there's a specific test case that fails when running as a limited user. The reason I don't test as a limited user is simply that I need to debug the audio service. And that service runs as LocalSystem (currently, we're trying to understand if we can change that). So at a minimum, I need the debug privilege.

    Our test team DOES run all the tests as a limited user, and their test results matrix knows which tests should fail in that case and which should not (for instance the tests that stop the windows audio service fail when running as a limited user).
  • How would I get notified about Windows Update updates if I was not running as an admin? As a developer I really don't feel like allowing windows to reboot my box whenever it feels like, there are quite a few nights when I am up working at 3 AM. And even some when I'm still up at 6 AM. And some when I'm already up at 7 AM. So picking a fixed time is just not an option. But the Windows Update (and Automatic Update) teams just assumed that as a regular user you don't need to know about available updates. Would it kill them to popup a balloon telling me there are updates available (the detection run as a LOCAL SERVICE anyways) and either prompt me for admin credentials to install the updates or just sit in the tray, remindimg me to login as an admin and install the updates?
  • Thanks for the update. That makes sense -- only using the least privilege you absolutely need (in this case, debug privilege).
  • As of Windows 2000 (IIRC) some of the MMC plugins did not work when invoked via &quot;Run as...&quot;, which would be the rough equivalent of running [su] under Linux or BSD. I don't know if that's the case in 2003.<br><br>The thing is to make it difficult to screw up or modify the state of the system significantly. In this regard, I think Linux is very good, though their implementation(s) mostly suck. There needs to be a way to go from admin context and back, with some visual clue that affects windows under the admin context, for example.<br><br>Also, Microsoft has to push OEMs (to ship boxes configured this way) and software vendors (to fix their apps so that they don't assume admin rights). As long as Dell and Gateway keep shipping XP Pro with a default admin account enabled by default not much will change. I suppose making every copy of Windows 98 disappear into a black hole would work as well.<br>
  • It's funny, I open the Date and Time control panel quite often, but never to change the time. (I've used SocketWatch for years.) I open the panel to see the time down to the second, or to see the date when the usual tooltip isn't working (it happens). It's fairly amazing that someone would lock a limited user out of this useful display panel. What were they thinking?
  • Michael, that's why I posted that example :)

    It's a case of UI design sillyness - the UI designers never considered that their control panel applet would ever be used for something OTHER than to set the time on the machine, so they didn't code it that way.

  • I'm hoping that once the new billing system for AC is in place, that stumbling block to running as a normal user will be removed. I'm not holding my hopes too high though, as AC modifies its data files during both the monthly updates and during play.

    It's good to see that things are getting easier to run as a limited user - I've not made the switch myself yet, but the machines I set up for other people are setup with limited user accounts. I'm probably going to give it a shot next reinstall.

  • Stephen, Ibn assured me that they're going to fix that problem with the new billing system. It remains to see if they can successfully execute on that promise, but...

    I suspect they've not yet considered what happens when a monthly patch happens.
  • After I gave myself SeShutdownPrivilege (I want to be able to hibernate my laptop), I find running as non-admin not that difficult. (Actually, there's a obscure interesting quirk with Windows's support for hibernate that I noticed as a result of this: if the logged on user has SeShutdownPrivilege, then you can tell the computer to hibernate by hitting the hibernate hotkey even if the user has locked the console with lock workstation. This is a bit weird because you can't shutdown without unlocking, but you can still hibernate.)

    It seems you have better luck than me with games; must every game I've played requires that I give myself write to it's directory (in %ProgramFiles%).

    Definitely agree with you on the Date & Time control; not being able to open that has bugged me quite a lot :)

    What I usually end up doing is keeping a cmd running as admin sitting around in case I have to mess with a control panel applet or debug a service -- works nicely.
  • Thanks for the suggestions. yeah, I realize the problem goes away with .NET 2.0. I'll look into them.

    Wally
  • Some bits of Computer Management are guilty - see for example Device Manager:

    "You do not have sufficient security privileges to uninstall devices or to change device properties or device drivers. Please contact your site administrator, or logout and log in again as an administrator and try again."

    Once you've OKed this box you find you can view quite a lot of options, and particularly see if a given device is actually present. You can modify serial port settings, if required (and if any!)

    My biggest annoyance is the lack of Run As on Control Panel applets. Partly this is because some of them should be MMC snapins, IMO - Control Panel is now something of a mixture between user profile tools and system administration tools (aka what the heck are Windows Firewall and Security Center doing in Control Panel anyway?)

    The trick as always is to come up with a way for things to happen without continually prompting for an administrative password. I always heard that Windows' "single-sign-on" was intended to prevent users from becoming anaesthetised to typing in their passwords - we want to consider carefully how we ask for an administrator password*, some way that can't be easily spoofed, and not do it so often that users follow the 'Install ActiveX Control' path, simply clicking to get rid of irritating prompts. [* - of course I mean 'the password to an account with the appropriate privileges', not necessarily the password for LOCAL\Administrator or even necessarily a member of BUILTIN\Administrators]

    Finally, MS needs to consider the difference between limited users on a domain, where there's a full-time administrator (very rarely asking for admin passwords), and limited users on their own home computers, where they really are the administrator, just choosing not to run with elevated privileges. Ideally even the full-time administrative staff should run without privileges until they're required. It's what I do at work (though I should set up separate administrative domain accounts and stop using DOMAIN\Administrator).

    Picky mode: Larry, have you got an auto-correct from 'principle' to 'principal'? "Principal of least privilege" should be "principle of least privilege", etc.
  • I'm really surprised to hear that Larry is *only* just starting to run as a limited user, especially after his post some time ago rebutting a supposed security vulnerability in XP SP2 caused by the user running as Administrator.
    How can he expect the public to run as a limited user when even the people that know about security don't?

    And yes, plenty of stuff apps sucks when running as a limited user or started using the runas command (InstallShield is one).
Page 1 of 3 (38 items) 123