Further Adventures of Don't Run as Administrator

Jonathan Allen of InfoQ took the time last week to bring up some points about my earlier article on not running as Administrator. I thought that there were two issues brought up that were worth going into more detail about.

The first issue is about the tooling available for HTTP security configuration. Jonathan writes,

In the XP SP 2 and Server 2003 versions of Windows, HTTP addresses and SSL Certificates can be reserved using "httpcfg.exe". As if to discourage developers from actually doing this, Vista does not have this application. Instead, one called "netsh.exe" must be used.

This blurb makes it sound as if netsh is taking a step backward from httpcfg, which is definitely not the case. It is, unlike httpcfg, a program installed with the operating system rather than a hard to find download and it is integrated with the configuration of the rest of the networking components. Both of those improvements are in my mind quite positive. What should be a point to discuss is that the ease of use once you have the tool isn't much improved (it's almost identical). You can argue that the tooling isn't going to be used that much because this is something that installers are supposed to take care of, but I've written elsewhere that I haven't seen many developers doing the small things that make the deployer's life easier. I expect that IT professionals will over time develop their own scripts and tools using the native API to take care of this chore, but I like the simplicity of having most developers satisfied by what comes in the box.

The second issue is more fundamental to the topic being discussed. Jonathan writes,

Since reassigning addresses must be accomplished as administrator, the installer must also be run as an administrator. Once again, we are back to encouraging users to run with administrator privileges.

I think that this requires me to reemphasize the point for why it is advantageous to not run services as an administrator.

I want the installer to require administrative approval because I want to control what happens to my machines. If I want to let people party on settings, then I can do that (via delegation of rights). If I want to lock things down, then I can do that too. It's my choice. Once I've configured everything the way I like, I don't want that mucked with.

I don't want the service itself to be privileged. A web service that runs normally at high privilege has a window of vulnerability that stretches out forever. The web service, by virtue of its nature, is going to be handling data across a boundary of control. The installer is something that lasts for a few seconds and that I can run when my computer is encased in lead and locked in a safe. Why spend any time thinking about what could go wrong when I can simply remove everything unnecessary to the problem at hand? It's easier to be defensive when you're defending a smaller space.

That's why I don't recommend writing a web service that asks to elevate to configure as part of its normal operation. That is a mode of design that makes both security and administration more painful later on. Take care of any issues up front and don't bother me again.

Comments

• Anonymous
  September 17, 2007
  I agree without hesitation.  I am therefore discouraged by installs that require internet access to operate successfully (hence triggering firewall permissions not available to limited users) and that often have to be run the first time with administrator privileges to configure properly (and to use the internet, condition the firewall, etc.). I just went through this with the Windows Live 2008 suite installer, and it didn't make me happy.  It's getting harder to find the non-web installs of development tools too.  Yuck.