Developing As Non Admin

Far too many Windows applications assume that they will be run by a user with administrative rights - just take a look at Known Problems and Keith Brown's Hall of Shame page. This assumption violates one of the basic requirements to be certified as "Designed for Microsoft Windows XP". The rest of this page explains what you can do as a Windows developer to avoid this problem.

#1 Educate Yourself

If you haven't already taken a formal course on Windows security, or worked through a good tutorial, now is the time to do so. Not being able to afford it is no excuse: Keith Brown has made his entire book "The .NET Developer's Guide To Windows Security" available online as a wiki (or you can buy it from Amazon).

#2 Develop As A Non Admin

There are several excellent articles about doing your everyday developer jobs while still running as a non-admin:

"Developing as non-admin with VS.NET 2003", by Anil John
"Developing Software in Visual Studio .NET with Non-Administrative Privileges" (MSDN)
"How to configure your development environment to develop with least privilege", step-by-step instructions from Anders Nor�s
"How To Develop Code As A Non Admin", from Keith Brown's online book (above)
"How To: Secure Your Developer Workstation" (MSDN)
"Myth: creating web applications with Visual Studio requires Admin privileges", by Jared Parsons
"Problems of Privilege: Find and Fix LUA Bugs" (TechNet magazine), by Aaron Margosis
"The Challenge of Least Privilege" (MSDN), by Michael Howard
"Visual Studio .NET User Groups: Use, Permissions, Security" (MSDN, as PDF article)
RegSvrEx, a utility that can register COM servers for the current user (CodeProject)
"TIP: Least Privilege and ASP.NET Debugging", by G. Andrew Duthie

#3 Test As A Non Admin

The first of the "Top Ten Tips for Secure Testing" from the Windows Hardware and Driver Central site is "Don't run tests as an administrator". You can use the tools and documentation in the Windows Application Compatibility Toolkit to verify that you can run as a limited-access user, or you can use LUA Buglight, a tool from Aaron Margosis designed specifically to help catch LUA bugs in applications.

#4 Get Ready For Longhorn

As Rick Samona explains in "Writing Secure Applications Using Least Privileges", there will be a new emphasis in Visual Studio.NET 2005 and Longhorn on least-privilege applications. You can read more in:

"Security in Longhorn: Focus on Least Privilege" (MSDN)
"Building Secure Client Applications in Windows Longhorn" (PDC '03)
"Fewer permissions are key to Longhorn security" (InfoWorld)

#5 Other Resources

Read Keith Brown on "What Is A Non Privileged User" and "Admin To Programmer" for why you want to develop non-admin code.
If you're really into this stuff, the Microsoft Research paper "A Black-Box Tracing Technique to Identify Causes of Least-Privilege Incompatibilities" describes how to work out why a particular system thinks it needs administrator privileges.

Comments

From Eric [131.107.0.91] - 4/29/05 1:31 PM

Here's a decent Code Project article discussing non-admin COM server registration to support running as non-admin : http://www.codeproject.com/w2k/regsvrex.asp

From Gert-Jan [194.3.183.35] - 9/14/05 11:54 PM

There's also an article by Microsoft titled "Visual Studio .NET User Groups - Use, Permissions, Security". Quoting the abstract:

When Visual Studio .NET installs, two special user groups are created: “VS Developers” and “Debugger Users”. This document provides an overview on the use, permissions, and security associated with Visual Studio group members for developing and debugging .NET Windows applications, web applications, and web services. Information includes configuration options for using Visual Studio from standard user accounts (non Administrator, non Power User), such as students programming Visual Studio on shared workstations in a computer learning lab.

See http://download.microsoft.com/download/f/f/8/ff8c8040-d1a7-4402-90df-5d1aaa7d37af/dotNETDevVSGroups.pdf

From aryan@adminfoo.net [24.16.96.33] - 9/17/05 8:58 PM

I had a problem where VS.NET 2003, installed (using Administrator account) on a brand-new WinXPSP2 system, kept wanting to do an install* any time I used the builtin help index to get info on a class, method, and so on. It was driving me nuts, as each of these install attempts would fail with error #1606 - and more to the point, would take 2-3 minutes! Arrgh! Oddly, even after the failed install attempt, the help screen I needed would in fact appear.

This was no good - it's like trying to drive while a monkey randomly steps on the brakes.

Finally I tracked down the twin problems, thanks to the verbose error text of MsiInstaller's 1004 error event. Essentially VS.NET was trying to access HKEY_CURRENT_USER registry entries that did not exist, since the installer had run under another account. The two keys were:

HKEY_USERS\S-1-5-21-2025429265-1390067357-839522115-500\Software\Microsoft\Shared Tools
HKEY_USERS\S-1-5-21-2025429265-1390067357-839522115-500\Software\Microsoft\Office\10.0\Common

Well, actually the place it wanted to find these keys was in HKEY_CURRENT_USER as previously mentioned. Note in the above we are looking at HKEY_USERS and the SID ends in 500 - that's the Administrator account. When Administrator is logged in, all keys under HKEY_USERS\*-500 appear as keys under HKEY_CURRENT_USER. So, using regedit.exe while running from the Administrator account, I exported the two keys (bulleted above) to files: shared.reg, and common.reg

Next I need to know my own SID, so that I can import the settings to my nonpriv'd acocunt's HKEY_USER key. In my case, locating my own sid was easy enough - I was the only other user on the machine, so I knew the only other HKEY_USER registry key with a full SID listed would be mine (ending in "-1004"). But if you aren't sure what your sid is, you can get WHOAMI from MS, and run like so:

c:\tools>WHOAMI /user /sid
[User] = "PURGATORY\bryan" S-1-5-21-2025429265-1390067357-839522115-1004

Knowing my SID, I did a simple search-and replace in the two *.reg files I had exported. I replaced "-500" with "-1004" throughout the files. Then I saved them and double-clicked them to import back to the registry. Result: I now have an exact copy of these keys as found in Administrator's profile.

Viola! VS.NET no longer keeps trying to install stuff when I access the lnaguage reference in the Help system.

-----
* "Please wait while Windows installs addtional Visual Studio .NET components" is the closest I can come to remembering what the dialog said.

From jonathanh - 3/25/07 4:15 PM

Eric and Gert-Jan, thanks for your suggestions - I've added them to the main page

�

Last Modified 3/25/07 4:25 PM