• Comments 13

As noted in a previous "blogsicle", I have a strange habit of wasting countless hours browsing Slashdot comments, alternating between abject horror and mild amusement at the outlandish things people post there.

Two things that are said time and time again about Windows are:

1)    In Windows, you have to run as Administrator.

2)    In Windows, every file is executable if it has the right extension.

The first claim is of course completely bogus. For better or worse, Windows makes people Administrators by default (otherwise, how would they install software, set the system time, add other users, etc?) but that doesn't mean you have to stay that way. I have been running as a "Normal User" (not even "Power User") for quite some time now (over a year?) on Windows XP with very few problems. Sure, it's a bit of a pain that I have to use RUNAS when I want to go to Windows Update and install a patch, but day to day it does not interrupt my routine. I can browse the web, use Microsoft Office applications, build apps with Visual Studio .NET, play music, and do pretty much whatever I want without any issues.

Now it's not all smooth sailing; setting up software can be a bit of a challenge, for several reasons. First, you have to run as Administrator in order to install most software. Trouble here is that some software is not written to take multiple users (or security conscious users) into account, and will do something like:

  • Install user configuration files into \Program Files\ or some other protected directory
  • Store user configuration information in HKLM or some other protected registry key
  • Refuse to run unless the application is installed per-user (with Admin rights)

The first two can usually be worked-around by adding weaker ACLs to the individual files or registry keys that the application uses, assuming of course that doing so won't weaken your system (eg, don't give All Users - Full Control to System32 just because an app writes a log file there). The third one usually requires you to temporarily add your "normal user" account to the Administrators group, but you can usually take yourself out again after installing the product.

Some apps simply won't work as normal user, either because they are not written with security in mind, or because by their very nature they require the user to be an administrator (ie, they do some pretty privileged operations as part of their normal processing), but you can generally get by just RUNAS-ing them. If they also need to access the network using your domain credentials, there's an easy way around that, too:

runas /user:Administrator %comspec%

This will get you a command prompt running as Administrator. I tend to set the background colour of this prompt to be bright red so it is easily distinguishable from normal command prompts.

runas /netonly /user:domain\username %comspec%

This will get you a second command prompt running with local Admin rights, but your domain credentials will be passed to other machines on the network. I tend to set the foreground colour to red so I can distinguish it from other command prompts.

Note that due to a current limitation in Windows, you can't shutdown the original command prompt that you RUNAS-ed, otherwise new applications you run as Administrator will not be able to draw on the screen. Why? Well, Windows has the concept of Window Stations and Desktops, which are both securable objects. By default, only "you" (the main logon user) can access your desktop, and so in order to let the Administrator account access the desktop, Windows has to setup the ACL correctly to include the Administrator. Trouble is, when you shutdown that original application, Windows removes Administrator from the ACL, thereby making it impossible for other applications to draw on the desktop. Not a good experience, and I learned the hard way :-). (The preceding description may not be 100% accurate, seeing as how I don't actually work in Windows security, but it should be close enough to give you the general idea).

As for the second claim -- all files are executable as long as they have the right extension -- it is only partly true. All files on NTFS volumes have an "Execute" security attribute (just as they have "Read" or "Delete") and you can deny Execute to everyone to stop files from executing. Unfortunately, this is a bit tricky to do since it also applies to changing directories, so in general people don't turn off this bit. What's more interesting though is the Software Restriction Policies feature of Windows XP / 2003, also known by the name SAFER.

SRP lets you specify which code is allowed to run on your machine, based on things such as the directory it is in, the extension it has, the publisher used to sign the code, and so on. To those of you familiar with CAS (code access security) in the CLR, this might sound familiar, although the features of SRP are not as rich as those in the CLR. So, for example, on my machine no code is allowed to execute unless it comes from the following places:

  • The Windows, System32, or Program Files directories
  • My Visual Studio .NET projects folder
  • The internal server used to install Microsoft applications
  • The netlogon and sysvol shares on the Microsoft DCs
  • Some other random folders for random software <grrr>

This works pretty well, especially since I don't have write access to any of those places except my VS Projects folder (remember, I'm not an Administrator) so it is virtually impossible for me to get infected with a virus that requires me to execute a program on my machine. Obviously I could still be infected with some kind of network worm like Blaster or Slammer, but then I follow other basic precautions such as running with the firewall turned on, unnecessary services turned off, and I keep up to date with Windows Update, so even those should not be a problem.

One thing to note is that using Windows Update with SRP turned on is virtually impossible, due to the way the patches work. Even though the patches themselves are digitally signed (so I could use a publisher policy) and they are downloaded to a well-known directory (so I could use a folder policy), they tend to be self-extracting EXEs which extract other, non-digitally-signed EXEs into randomly named folders. So for that I have to temporarily turn off SRP for the Administrator account, or, if I'm lucky, I can manually extract the patches and run them from a known location.

I also browse the Internet in IE with the "Internet Zone" set to the highest possible level, and then I have defined custom zones for holding "partially trusted" sites by hacking the registry. Maybe more on that later, because I don't think it is officially supported ;-). Oh and I have both Outlook and Outlook Express run with all mail set to "plain text", so no annoying graphics or potential security problems with HTML mail. And I set my CAS settings in the CLR to block code from everywhere except my local machine and a few other trusted machines. Hmmmm anything else? Not that I can think of right now.

Anyway, this entry turned out to be much longer than I expected... oh well.

P.S. I hate the latest Microsoft Security Patch virus with a passion. I have received many hundreds of these stupid e-mails in the past few days...

  • I pull a similar trick to run IE under a limited security context as well. I simply runas iexplore under a very limited guest account with almost no filesystem access whatsoever (except a folder I call dropzone where I can save files from the web, and upload from etc.). I hacked the registry for this very limited account to color it's windows with a red border so my "secure" IE windows all pop up decorated as such. This way, even should I catch a nasty IE bug, it wouldn't have permissions to any of my files/etc.
  • That's another good idea. Hopefully you do the same with your e-mail client ;-)
  • An additional hint I read somewhere else: if you need administrative access to a folder, run runas /user:Administrator "C:\Program Files\Internet Explorer\iexplore.exe" then type the location of the folder into the address bar of the new IE window (or use the Folders pane). Helpful for Control Panel, which has no other way to run an applet with different credentials (this should definitely go into Longhorn...)
  • Although it's possible to tweak Windows to run with weaker permissions I think a lot still need to be done to fully separate application code/user's data and make it easy to manage. Obviously effort is needed on both Microsoft and third parties sides to play the game..
  • Great to see some other folks running with least privilege on Windows. I've been doing it for about four years, and it's pissed me off enough seeing all the software that breaks that I ranted about it in my book[1].

    There's some great tips in that chapter for folks trying to develop code as non-admins.


  • Andrew / Peter Torr,

    (A bit late to the conversation)

    I am wondering wether the situation that Andrew describes of having the "Runas"'ed programs appear in a different window colour works (on Windows XP).

    I setup a second account with a Windows Classic theme with red borders, and when I runas programs from my own account with the second account the programs use my own theme rather than picking up the second accounts themes. I have tried as much fiddling in the registry as I know for the Window colours section. Any tips on wether this is doable?
  • AFAIK you can't do that -- I've tried that trick myself before and failed ;-)

    What you CAN do is change the background colour of the CMD window, or set a background bitmap for IE / Windows explorer.

  • Thanks for the response Peter, I had figured out the cmd prompt colouring, I hadn't thought about the background bitmap for explorer. I had completely forgotten about that functionality.

    Perhaps Andrew might read this one day and let us in on the secret...

  • OK, the last entry was a teaser for a blog entry or two on what developers can and IMHO should do regarding...
Page 1 of 1 (13 items)