A few weeks back, Microsoft UK’s Steve Lamb presented a session on using the principle of least privileged access to reduce exposure to security threats under Windows (basically, running as much as possible as a standard, non-administrative user). Unfortunately I missed the event but I was chatting with Steve last week and he filled me in on the basic principles (which I’ve padded out with a few notes from his slidedeck).

The runas command can be used to start a program as a different user (as programs inherit their permissions from the parent process, starting a cmd shell as an Administrator and then launching an application will launch that application as an Administrator. Within the Windows GUI, there is often a right click option for runas, although for control panel applets shift and right click is used to expose the runas option. Shortcuts can be modified to run with different credentials for applications that always require a higher level of access.

There are occasions when runas just doesn’t work – for example applications that reuse existing instances (Windows Explorer, Microsoft Word) or those that are started through the shell using the ShellExecute() API call or dynamic data exchange (DDE). Unfortunately Microsoft Update is one of those applications for which runas won’t work. Aaron Margosis has some advice on his blog to help work around issues with runas and Windows Explorer.

Privileged command shell windows can be set apart using a different colour scheme, for example:

cmd.exe /t:cf /k title Administration Shell

For the GUI, the TweakUI power toy can be used to set an alternative bitmap for Internet Explorer and Windows Explorer, or Aaron Margosis’ PrivBar displays the current privilege level.

Whilst it’s true that using a local account will prevent domain-wide issues, there are side effects in that there is no access to domain resources, different profile settings (and per-user policy settings) are in effect and some applications assume that the installer is the end user. One possible resolution is Aaron Margosis‘ MakeMeAdmin tool which allows for temporary elevation of the current account’s privileges (and any applications which inherit the user context. MakeMeAdmin can be downloaded from Aaron’s blog and he has a later follow-up post with more information.

Some applications are written to run as Administrator and there’s not a lot that an end user can do about poor coding (other than replacing the application with something else). Adding the user to the local Administrators group to resolve such issues is not good practice, although it may be possible to loosen the ACLs on application-specific resources (i.e. %ProgramFiles%\applicationname\ and HKEY_LOCAL_MACHINE\SOFTWARE\applicationname\Settings) but this should not be carried on operating system resources (e.g. %windir%, %windir%\System32 and
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows). The important thing to remember is to do this in a granular fashion, applying additional permissions only to those resources to which access is required.

If an application writes to HKEY_CLASSES_ROOT, then it’s usually a bug. HKEY_CLASSES_ROOT is a merged view of HKEY_LOCAL_MACHINE\SOFTWARE\Classes and HKEY_CURRENT_USER\SOFTWARE\Classes so writing to HKEY_CLASSES_ROOT effectively goes to HKEY_CURRENT_USER if the key already exists. Consequently, problems with HKEY_CLASSES_ROOT can often be overcome by pre-creating keys under HKEY_CURRENT_USER.

If all else fails, utilities such as MakeMeAdmin can be used to allow an application to run with elevated privileges but they require the user to know the Administrator password – alternatives include Valery Pryamikov‘s RunAsAdmin and DesktopStandard PolicyMaker Application Security.

In Windows Vista, everything changes again with new functionality known as user access control (also known by other names including user access protection and flexible account control technologies):

• All users run as an unprivileged user by default, even when logged on as an Administrator.
• Once running, the privilege of an application cannot be changed.
• Administrators only use full privilege for administrative tasks or applications.
• Users are prompted to provide explicit consent before using elevated privilege, which then lasts for the life of the process.
• A high level of application compatibility is achieved using redirection (which allows legacy applications to run as a normal user with HKEY_LOCAL_MACHINE\Software access being emulated by a virtual location under HKEY_CURRENT_USER and attempted writes to the %SystemRoot% and %ProgramFiles% folders being redirected to a per-user store); however this is a temporary mitigation for 32-bit product versions only (i.e. not implemented in 64-bit versions of Windows Vista).

Although Windows has come a long way to making least privileged access usable, it’s important to remember that there are some things that least privileged access can’t guard against:

• Anything you can do to yourself.
• Weak passwords.
• Attacks on services.
• Phishing.
• Stupidity.

Unfortunately I’m writing this post on the notebook PC supplied by my employer with a standard corporate build and my domain account is also a local administrator. I think that probably falls into the last category listed above… doh!