As noted in a previous
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

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
  • Store
    user configuration information in HKLM or some other protected registry
  • 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:domainusername %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
and Desktops, which are both securable
. 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

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

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

  • 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

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...

Comments (13)

  1. Andrew says:

    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.

  2. Peter Torr says:

    That’s another good idea. Hopefully you do the same with your e-mail client 😉

  3. Mike Dimmick says:

    An additional hint I read somewhere else: if you need administrative access to a folder, run

    runas /user:Administrator "C:Program FilesInternet Exploreriexplore.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…)

  4. Daniel Fernandes says:

    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..

  5. Keith Brown says:

    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.



  6. Chris Ormerod says:

    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?

  7. Peter Torr says:

    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.


  8. Chris Ormerod says:

    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…


  9. OK, the last entry was a teaser for a blog entry or two on what developers can and IMHO should do regarding…

Skip to main content