Running As Normal User

As most of you probably know, Microsoft is a land of acronyms. We mostly prefer the 3-letter variety here (TLAs), but I've been spending a lot of time lately thinking about one of the 4-letter ones: RANU. RunAs Normal User.

Just to be clear about what I mean, I'm talking about one of the hurdles we set and will clear for Visual Studio - the Visual Studio environment must be able to run when the logged-on user has only* Normal User privileges (that is, does not belong to the Administrator or Power User groups). I put an asterisk there because I'm sure there will be various exceptions to the rule, but that's generally a pretty rigid criteria.

Note that this applies to the Team System client features as much as the rest of Visual Studio, which is why I've been thinking about it a lot lately. Being able to run as Normal User is an important layer of defense when it comes to using your computer securely -- that's a big part of where the requirement comes from. The fact that many corporate LAN users aren't admins on their machines is a concrete demonstration of both the value of the defense and the need for our software to play well with it.

Yet, as has been said elsewhere, FAR too many people out there are admins on their machines. Even I'm guilty of it. There are various reasons, even a few reasonably-valid ones. This sort of strays into the territory of where if the user can't do something painlessly, it's just not good enough yet. In some ways it doesn't matter if a feature is there, if it's well-documented, if it's A Best Practice, etc. -- if it doesn't just work, then it isn't done yet.

Windows is, as a product of its own history (IMHO), at this point as far as the default user being an Administrator is concerned. There *are* now various facilities there that make it very *possible* to run as a normal user by default, and temporarily elevate to Admin privileges when necessary, in a controlled fashion. But it's by no means painless/discoverable/easy -- however you want to characterize it. That's part of the problem. The other problem, of course, is that too much software out there - some MS software to be sure, but boatloads of 3rd-party software as well - either take for granted that the running user is an Admin, or (essentially) require the user to be, sometimes with spectacular results if they're not.

For example: Practically every PC game out there - *still* - seems to expect the running (not just installing) user to be admin. They want to write/modify some set of files that live in their install folder - %systemdrive%\program files by default. Well, as some of you know and others may not, Joe Normal User can't modify or create files anywhere under Program Files (by default). There are a few games out there that store configuration/save data in better places, such as under Documents and Settings\<current user> somewhere, but they still seem to be the exception rather than the rule.

As long as it's hard to run as normal user - either because the OS doesn't help you deal with it, or because lots of software expects it, or both - it will be hard to convince many users out there to "play it safe", because it's too much work and you may never see a return on your extra effort (after all, it is a layer of defense, hardly the only aspect of safe computing). But, it's something I'm going to start pushing myself to do, and I figure it's a good thing to start encouraging others to do as well.

Now, on to the good news and a group "challenge". I said it's still not easy to "RANU", but I want to see just how easy I can make it, with your help. I started to write up some features and tips/tricks I've picked up over time about how to deal with this, but I just got pointed at Peter Torr's thoughts on the subject, and he did a great job of covering what I know about the subject and then some. So, take a look at his post and feel free to post your own thoughts, any additional tips or tricks you know about, and so on. It will ultimately fall to the Windows team to really make this layer of defense as painless as possible, but that doesn't mean there's nothing we can do in the meantime.

Comments

• Anonymous
  October 26, 2004
  I just finished writing an update program that I knew would be run exclusively by members of the "Power Users" group, so programming with diminished priveleges was very important during the development. I'd actually prefer to do everything this way, but the one sticking point I've had is that I can't debug without at least being a member of "Debuggers". I know that I shouldn't need to step though my program if I want to qualify as a hairy-chested he-nerd. I should be able to just look at my code and know the state of everything at any time. But I'm just not that good yet. I'm still haunted by my memories of my Alma Mater's computer lab... eleven hours to re-create an OpenGL program from memory as a result of a hard drive crash... I sit down with full confidence that I could do it, only to find that I can't step through my code, because I'm RANU. What would have taken me till 5pm took me until 11:56:00pm (it was due at midnight) because I had to debug everything with the artful use of afxmessagebox-es. So RANU is very scary for me. What I did on this last project was to look closely at my specs, and figure out what might cause problems when RANU on the specific platform I was writing for(accessing the network, writing to the registry, running install packages, adding, replacing and deleting files), and taking these limitations into account. I didn't want the program to crash or fail ungracefully if it tried to do something without the right security level. Although I programmed as an Administrator, I would test the program as the target user (Power User) at key points in the development cycle. It was a little bit easy for me, in that I knew the program would always be run as a "Power User," but the whole process showed me how important it was to take user privelege levels into account while programming and testing.
• Anonymous
  October 26, 2004
  The comment has been removed
• Anonymous
  October 28, 2004
  The comment has been removed