Aaron Margosis' "Non-Admin" and App-Compat WebLog : Non-admin for home users

Anti-virus vs. Non-Admin

Aaron Margosis — Fri, 02 Jun 2006 16:43:00 GMT

This may be controversial, but I truly believe it and I'll say it:

With today's threat landscape and the way malware works today, you are better off running as non-admin WITHOUT anti-virus than you are running as admin WITH anti-virus.

If your anti-virus/anti-spyware/anti-malware software requires that you run as administrator in order to protect you, GET RID OF IT. It is not worth the cost. As Paul Coddington put it, it's "sort of like having a burglar alarm that only works when your house is unlocked and the doors are open."

Most if not all of the most prevalent malware out there today simply will not work if it runs with non-admin privileges. That will change over time -- especially after the release of Windows Vista -- which is why I preface my assertion with "With today's threat landscape". Hopefully by then, anti-malware solutions will have changed, too.

[Addendum - June 4, 2006, 2220 EDT] I would like to clarify one point: If you are running as non-admin, you are better protected if you have good, up-to-date anti-malware that works well as non-admin than if you have no anti-malware protection at all. (On the other hand, if the anti-malware contains bugs in high-privilege code or exposes other elevation of privilege paths, maybe you're not!)

I'm Back! Upcoming Posts...

Aaron Margosis — Sat, 04 Feb 2006 09:06:00 GMT

It's been way too long, but I'm going to force myself to find the time to get more "least-privilege" information posted here. Most of my posts til now have been about ways for those of us who administer our own machines to run Windows as a non-admin, invoking administrator privileges only when truly needed. That's one of the "least-privilege" challenges of Windows today. There is another (possibly bigger) challenge: what about users who should always run as non-admin? The 10,000 "information workers" in your enterprise, the children on your home computers -- you do not want to give them the administrator password (directly or indirectly), or have them making security decisions about when administrator privileges should be used. Yet they need to run programs with "LUA bugs" -- programs that don't work unless they run with administrator privileges. How can those users run as non-admin?

Too often, this second challenge is addressed by simply having the users/children run as administrators, by unsafely opening up access control to large portions of the file system and registry, or by "encrypting" an admin password into a special program that runs another program with admin privileges.

In upcoming posts, I'll write on topics such as:

What exactly is a "LUA bug"? (And what isn't a LUA bug?)
A systematic approach for working around LUA bugs that avoids unnecessary exposure
How to identify LUA bugs using Regmon and Filemon
"LUA BugLight" (a new tool for identifying LUA bugs -- still in development!)

It's good to be back!

Running restricted -- What does the "protect my computer" option mean?

Aaron Margosis — Fri, 10 Sep 2004 07:05:00 GMT

If you’ve been reading my “non-admin” posts, by now I assume you have seen the Windows XP “Run As” dialog. (If you haven’t, please read this post first: "RunAs" basic (and intermediate) topics.)

The initial settings when the “Run As” dialog opens are to run the program as the current user, with an option selected to “Protect my computer and data from unauthorized program activity”. It further states that “This option can prevent computer viruses from harming your computer or personal data, but selecting it might cause the program to function improperly.” What does that mean? How do you decide whether to use it? As far as I know, there hasn’t been any accurate public documentation about the “protect my computer” option, let alone any guidance as to when it might or might not work for any particular application.

The net effects

The bottom line is that the app runs with a “restricted token” that basically has these net effects:

Group membership: If you were logged in as a member of Administrators, Power Users, or certain powerful domain groups, the app runs without the benefit of those group memberships.
Registry: The app has read-only access to the registry, including HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE. The app has no access to HKCU\Software\Policies.
File system (assuming NTFS): The app cannot access the user’s profile directory at all. That includes “My Documents”, “Temporary Internet Files”, “Cookies”, etc.
Privileges: The app has no system-wide privileges other than “Bypass traverse checking”.

These are very powerful restrictions, particularly those around the registry and profile folders. It’s probably a safe bet that most apps do not expect “access denied” errors when writing to HKCU or the user’s temp or MyDocs folders, and probably do not handle such errors gracefully. When I tried to use Outlook Express with “protect my computer”, it failed to start up at all. This isn’t entirely surprising – all its data is in the user’s profile folder hierarchy.

The only thing I ever really use with “protect my computer” is Internet Explorer when I want to really constrain a particular site and not allow it to write to my hard drive at all. (Note that this is only an additional element of defense in depth, not an entire defense.) IE works fairly well this way, but with some odd and annoying problems:

You can’t use SSL (https) at all.
If you right-click on a hyperlink and choose “Open in New Window”, nothing happens.
If you enter a URL in the address bar without “http://” in front of it (e.g., “www.msn.com”), you get an error message like “C:\Documents and Settings\aaronmar\Desktop is not accessible. Access is denied.”, before IE goes ahead and loads the site anyway.
On XP SP2 and on Server 2003, toolbars do not appear where you configured them, if they appear at all. E.g., PrivBar always needs to be re-enabled; “Links” appears (on my machine) in the upper left, to the left of the menu bar. (This wasn’t a problem with XP SP1.)

That’s about all the “guidance” I’ve got as far as what to expect if you use the “protect my computer” option. If anyone really cares, I could write a lot more about the geeky details around restricted tokens, deny-only SIDs, how access checks are performed against restricted tokens, which groups get marked deny-only with “protect my computer”, etc. But maybe Larry Osterman will save me the trouble and follow up on some of his recent security posts (e.g., What is this thing called, SID?)

"Zero-day" attacks and using limited privilege

Aaron Margosis — Fri, 25 Jun 2004 19:55:00 GMT

There have been a couple of credible sounding stories in the press in the past week or two about zero-day attacks - that is, the malicious exploitation of previously unknown vulnerabilities. I think we're going to start seeing more of these, as the bad guys better understand the economic value of finding and exploiting vulnerabilities.

Hackers used to be satisfied just vandalizing web sites. The next cool game was to find a bug and be the first to publicize it - and yourself for finding it. Many of these “analysts” now play the game more responsibly, alerting the vendor first and not publicizing the vulnerability until the vendor releases a patch. And of course there are the malware writers, releasing often poorly-written worms, trojans, etc. such as Sasser into the wild and getting big headlines. The damage many of these have done, though, has often been limited to consumption of network bandwidth and the time of IT administrators. Very few of these have exploited vulns for which there was no fix available.

In the past year or so, we've started seeing the increasing spread of malware with an economic purpose. In particular I'm thinking of the ones that allow users' computers to be controlled by spammers. Many Internet domains and IP address ranges have become known for hosting spammers and end up on spam filter blacklists. By turning your computer into a zombie and having their bulk mail originate from your DSL line, spammers bypass these filters. Why do they go to all this trouble, and even break the law? Because they make a lot of money doing it! Spam still generates big revenue. We've also seen increases in phishing and spyware - ways to get your private information for someone else's illegal gain.

I think we can expect to see more cases where people who find new security vulnerabilities will not alert the vendor or otherwise publicize their findings, but instead use the information for financial gain, by installing spyware and spam engines on victims' computers -- particularly when the “researchers“ and/or the people they do business with live in places like Russia where the legal risks are relatively small.

So what does this have to do with running as a Limited User? Will running as a Limited User rather than an Administrator keep you safe against these zero-day attacks? Well, it depends on the attack. If the exploit attacks an operating system service, as Sasser and Blaster do, then it doesn't even matter whether anyone is logged on, let alone whether they are an admin. (Use a firewall.) But if the vulnerability is exploited through your web browser, email, IM, internet-connected game, etc., then the malicious code can do anything you can do. See the “#1 reason” paragraph of Why you shouldn't run as admin for why this matters so much. Running as Limited User might block the attack completely, and in any case it will certainly limit what the attack can accomplish.

Running as Limited User does not by itself make you secure, but it is an important piece of defense in depth. It is vitally important to use a firewall and to keep up-to-date on patches and anti-virus signatures. These will block many of the bad things out there from affecting you. But there are exploits that will bypass all of these. In these cases, running as Limited User may be the only line of defense you'll have left.

"RunAs" basic (and intermediate) topics

Aaron Margosis — Wed, 23 Jun 2004 08:46:00 GMT

In this posting:

What is RunAs?
How to use RunAs from the GUI (even if you can’t see it)
Using RunAs from the command line
When RunAs won’t work
Useful RunAs shortcuts and related tips for the non-admin

Did you know that millions of people run as non-administrator every day? It’s true! What do they do when they come to a point where something requires administrator privileges? Simple: they call their helpdesk. And if they ask really nice, a sysadmin makes a note to stop by sometime within the next month. When he arrives, he logs in as administrator and performs some magical administrative tweak that renders the user’s computer unbootable. “Oops!” Of course, that’s not really true. The sysadmin can now log in remotely to render the user’s computer unbootable, without even leaving his desk! (I’m sure there’s research going on somewhere about how remote administration is contributing to increased sysadmin obesity.)

If you are your own helpdesk (i.e., you administer your own machine), how do you run something with admin privileges? Fast User Switching is the best option (see previous blog entry), but it isn’t available in Windows XP if your computer is joined to a domain. You can log out, shutting down all your apps, and log back in as administrator. Sometimes that will be necessary (I needed to do that when installing the beta of Microsoft Office 2003), but most of the time logoff is more disruption than necessary. At these times, the Secondary Logon service is your friend, typically exposed through RunAs.

The Secondary Logon service was first introduced in Windows 2000, and is in Windows XP and Server 2003. When you start a new process through RunAs, you provide credentials for the account you want the process to run under – for example, the local Administrator account. Assuming the credentials are valid, the Secondary Logon service then causes several things to happen:

creates a new logon session for the specified account, with a new token;
ensures that the new process’ token is granted appropriate access to the current window station and desktop (the specifics change somewhat for XP SP2, but aren’t important here);
creates a new job in which the new process and any child processes it starts will run, to ensure that the processes are terminated when the shell’s logon session ends (correcting a problem with the NT4 Resource Kit’s SU utility).

Is this description too nerdy? The net is that it lets you run programs as a different user on the same desktop with your other running programs. The new process and (generally) any programs it starts will run under this new account.

The “How to develop code as a non-admin” item in Keith Brown’s upcoming book, A .NET Developer's Guide to Windows Security, covers some of the same ground I’m covering here. We cover the details differently and offer different tips, though, so you should read us both!

RunAs GUI, in Windows XP and Server 2003:

In Windows Explorer or the Start menu, right-click on any Application (.exe) or Microsoft Common Console Document (.msc) file or shortcut, and choose “Run As…” from the context menu. In the “Run As” dialog, choose the 2^nd radio button (“the following user”) enter the user name and password for the account, and click OK. (I’ll discuss the first radio button and the “protect my computer and data…” option in a future post.)

I said “any”, but that’s not quite true. If the shortcut is a “special Microsoft Windows Installer link”, you’ll need to hold down the Shift key while right-clicking to get Run As on the menu. (Don’t ask me why. It’s better than in Windows 2000, where you never saw Run As on the right-click menu unless you pressed Shift.) On my Start menu, these “special” shortcuts include Adobe Reader 6.0, MSN and Windows Messenger, and MapPoint 2004.

The “hold down Shift” trick is also needed to get Run As on the context menu for most Control Panel shortcuts – specifically those that link to a .cpl file. RunAs doesn’t work for all Control Panel items, though. Some of them, such as Folder Options, Fonts, Network Connections, and Scheduled Tasks, actually run within Windows Explorer, which by default doesn’t play well with Run As. More on that in a future post.

There’s also a little problem with the Power Options applet. According to Keith Brown’s analysis (no longer online? I can’t find it), when you click OK or Apply, it writes both per-machine and per-user settings. If you are a normal User, it quietly fails when writing the per-machine settings and never writes the per-user settings. (As of XP SP2 RC1, this is “fixed” in that it at least tells you that it failed to save the settings.) If you use RunAs to run it as the local administrator, the per-user settings it writes are those of the administrator account, not your user account. Sadly, to change your own power settings, you need to be an admin. (This is addressed by my MakeMeAdmin script, which I’ll describe in an upcoming post. Stay tuned!)

You can avoid the right-click context menu and make “Run as…” the default action for a particular .exe or .msc shortcut by opening its Properties dialog, clicking Advanced, and checking “Run with different credentials”. When you invoke the shortcut, you’ll get the RunAs dialog, and the shortcut’s target will run under the account you specify.

RunAs from the command line:

RUNAS.EXE is a console (a.k.a., “text mode”) application that prompts for alternate account credentials and starts a new process under that account. Console applications are often started from a cmd.exe command prompt, but they can also be started from the Start/Run dialog or from an Explorer shortcut.

RUNAS.EXE offers more flexibility than the GUI, including the ability to authenticate with a smart card, to use the account only for network authentication but continue to use your current account locally, and to control which profile and environment to use. Type “RUNAS” without parameters at a command prompt to see its command line options. Look up “runas” in Windows XP Help and Support for more info and examples.

When RunAs won’t work:

A common source of frustration and confusion is to start an application with RunAs, only to find that it is continuing to run in your original logon session. (First, how do you tell? My favorite tool here is Process Explorer from SysInternals. Add “User name” to the displayed columns. Starting with v8.30, ProcExp no longer requires admin privs – thanks, Mark! Also look for my PrivBar utility in another upcoming post.)

The problem is that when started, many applications – such as MS Word and Windows Explorer – look on the current desktop for an already running instance of itself. If found, the new process will send a message to the previous instance to handle the request and then exit. That previous instance will often be running under the account you originally logged on with, not that of your alternate credentials. A similar effect occurs when a new app is not started directly by the parent app, but is instead started through the shell, via ShellExecute[Ex] or through DDE. The new process then inherits the security context of the shell, and not of your alternate account. The cmd.exe start command will do this in certain circumstances.

I promise to discuss how to get Windows Explorer to play nicer with RunAs in a future post. In the meantime, Keith Brown’s “How to develop code as a non-admin” describes how you can use Internet Explorer to achieve some of the same results (search the item for “But I hate the command prompt!”).

Some tips and tricks:

I really like Keith’s recommendation to change the background bitmap for your admin IE, but there’s an easier way to do it: the TweakUI Power Toy. Run it as admin and navigate to Internet Explorer \ Toolbar Background. And here’s a bitmap I like to use.

Many people like to keep a cmd.exe shell running as local admin. To reduce the possibility of mistakes, I strongly advise making it obviously different from your normal command shells. The easiest, one-time setup is to click on the admin shell’s system menu, choose “Defaults” and change the colors. This is a per-user setting, so all future console windows running as local admin will appear in the colors you choose.

Another way is to specify distinguishing characteristics in the cmd.exe command line. For example:

cmd.exe /k cd c:\ && color fc && title ***** Admin console *****

The /k option says to run the commands that follow, and not exit after running them. (FYI, /c runs the commands and then exits.) The commands that are executed change the current directory to the root of C: (somewhat safer than being in the system32 folder), the color command changes the console’s color to light red on bright white (run “color /?” to see other choices), and the title command changes the window title to something distinctive. I keep a shortcut in my Quick Launch bar that invokes runas with that command line.

Yet another way, suggested by MS employee John Lambert (NT), is to associate a custom icon with the shortcut. The icon will appear in the Alt-Tab window, the taskbar, and of course the upper-left corner of the cmd window itself. Note that this works only with a cmd.exe target, and you need to use the GUI RunAs option, not the runas.exe console app. Here is an icon you can use.

The admin command shell is a popular way to start apps with elevated privileges. You don’t have to be a total nerd to enjoy its power, though. Examples:

Windows Installer Packages (.msi files) don’t offer a RunAs context menu option. You might be able to get away with hacking the registry to add that option, or you can just run the .msi file directly on the command line of your admin shell.

In general, the command shell recognizes file associations, so you can invoke a data file on the command line and it will start the associated application.

You can start Control Panel applets from the command line just by typing the name of the .cpl file. Some examples:

Start “Date and Time Properties”:

C:\>timedate.cpl

Start “Add or Remove Programs”:

C:\>appwiz.cpl

Start “System Properties”:

C:\>sysdm.cpl

To start Internet Explorer from the command shell, you can type the full path ("C:\Program Files\Internet Explorer\iexplore.exe" – rather a PITA even with command completion). I just keep an ie.cmd file in a folder in my path (posted here as a .txt – just rename it to .cmd). It starts IE, and takes an optional URL parameter. E.g.,

C:\>ie blogs.msdn.com

That will have to do for now. Please continue to post comments, and I’ll try to get everything addressed.

The easiest way to run as non-admin

Aaron Margosis — Fri, 18 Jun 2004 03:13:00 GMT

Upcoming posts in my LUA/non-admin track:

Using secondary logon (RunAs)
Running control panel applets as admin
Using RunAs with Explorer
Temporarily elevating your current account to admin without logging out
Running with a restricted token (what does “protect my computer and data from unauthorized program activity” actually mean)
“etc.”

But first, the low-hanging fruit: how to help your non-techie friends and relatives run with least privilege. Interestingly, the problem of running as admin only when needed is best solved today in Windows XP Home Edition (and XP Pro, when not joined to a domain). From KB article 279765, HOW TO: Use the Fast User Switching Feature in Windows XP:

“In Microsoft Windows XP, if you enable the Fast User Switching feature, multiple user accounts can log on to a computer simultaneously…. [U]sers can switch sessions without closing Windows, programs, and so forth. For example, User A is logged on and is browsing the Internet, User B wants to log on to their user account and check their e-mail account. User A can leave their programs running while User B logs on and checks their e-mail account. User A can then return to their session where their programs would still be running.”

With FUS, you can be logged on as a Limited User, switch to a Computer Administrator session without having to close your apps, do your admin stuff, and switch back to your LUA session. FUS is easier to use than RunAs, and lets you run any app (unlike RunAs). It’s also more secure, since logon sessions are isolated from each other and do not share a common desktop. To switch from one session to another, click the Start button, Log Off, Switch User. Or more quickly, just press Win+L (Windows key + L).

Here’s how I set up home computers for friends and relatives:

Create a Computer Administrator account called “Admin”. No password. (Read on before you flame.)
Create a Limited User account for each person who will be using the computer. No passwords.
Enable the Guest account if it is anticipated that visitors may need to go online.

I instruct all concerned that the Admin account is to be used only for installing software, and to use their individual accounts for all day-to-day use, including web, email, IM, etc. This has worked quite well for everyone I’ve done this for, and don’t get calls anymore about home pages being hijacked, etc. Users generally don't even have to log out. My 7-year old walks away, the screen saver kicks in, my 3-year old moves the mouse and clicks on his picture (or the frog or whatever it is now) and has his own settings.

[added 2004.06.22]: I also like to make the admin desktop noticeably different from normal user desktops, to help prevent accidental use. For example, use the Windows Classic theme instead of the XP default, set a red background, or a wallpaper that says “For admin use only. Are you sure you need to be here?”

OK, I know you’re bursting already: “No password?!?! Are you insane?!?!” Cool down, now. Starting with Windows XP, a blank password is actually more secure for certain scenarios than a weak password. By default, an account with a blank password can be used only for logging on at the console. It cannot be used for network access, and it cannot be used with RunAs. The user experience of just clicking on your name to log on can’t be beat for simplicity. If you can trust everyone who has physical access to the computer not to log on as someone else or abuse the admin account, this is a great way to go. If not, you can always enable passwords.

What about applications – perhaps games originally designed for Win9x (“Wintendo”, as David Solomon calls it) – that unnecessarily require admin privileges? To be honest, I haven’t had to support gamers, so hopefully someone with more direct experience can chime in here. I’d start with KB 285909, How to Troubleshoot Program Compatibility Issues in Windows XP. I do admit to punting on TurboTax and just running it as admin. I weigh the risk of running TurboTax as admin vs. screwing up my taxes, and I’m just more afraid of the IRS. (I saw a discussion somewhere on the Internet about TurboTax requiring admin – I’m not the only one who was forced to punt.)

A valid question that often comes up (and came up in a reply to one of my earlier posts) is, “why isn’t LUA part of the out-of-the-box-experience for Home Edition?” I’m not on the Windows team and wasn’t party to those decisions. But as I understand it, there simply wasn’t time in the XP timeframe to address all the issues to make Limited-User-by-default satisfy user expectations and provide a good user experience out of the box. There is always a balance between security and usability, and at that time, usability would have suffered too much for too many people. Remember that the vast majority of home users were using Windows 98 and Windows ME (“the last version of MS-DOS,” I call it), and apps designed for that platform. I think we can expect that it will be a lot better in Longhorn.

One last caveat: Fast User Switching and RunAs do not play well together. Use one or the other, but not both at the same time. You could end up having to hit the reset button. [Added 20 June 2005:] This caveat applies only to XP RTM and XP SP1. The underlying bug was fixed in SP2, so now you can use FUS and RunAs together with no problem.

Why you shouldn't run as admin...

Aaron Margosis — Thu, 17 Jun 2004 11:47:00 GMT

First, let’s define terms. This may be oversimplifying, but for the purpose of this discussion there are only two types of users: Administrators, and Users. They are essentially distinguished by membership in the “Administrators” and “Users” local groups. “Administrators” have complete and unrestricted access to the computer/domain. “Users” are prevented from making accidental or intentional system-wide changes.

Narrowing down to two user types is not entirely arbitrary. In fact, this is exactly how Windows XP Home Edition distinguishes users. Under the hood, its Computer Administrators and Limited Users are members of Administrators and Users, respectively. And besides, membership in groups such as “Power Users” or “Backup Operators” is tantamount to being an Administrator. When I talk about running as non-admin, I am not suggesting running as Power User instead.

OK, so if you are one of those people who is allowed (or required) to administer your own computer, why wouldn’t you just want to log on as an admin all the time? Well, if you were a surgeon, would you always want to hold an unsheathed scalpel in your hand? Or would you prefer to keep it in a safe place until you actually need it? Does that metaphor work? How about “running with sharp scissors”? Well, let’s skip the metaphors, then.

The #1 reason for running as non-admin is to limit your exposure. When you are an admin, every program you run has unlimited access to your computer. If malicious or other “undesirable” code finds its way to one of those programs, it also gains unlimited access. A corporate firewall is only partial protection against the hostility of the Internet: you still browse web sites, receive email, or run one or more instant messaging clients [added 2004.06.25] or internet-connected games. Even if you keep up to date on patches and virus signatures, enable strong security settings, and are extremely careful with attachments, things happen. Let’s say you’re using your favorite search engine and click on a link that looks promising, but which turns out to be a malicious site hosting a zero-day exploit of a vulnerability in the browser you happen to be using, resulting in execution of arbitrary code. When an exploit runs with admin privileges, its ability to compromise your system is much greater, its ability to do so without detection is much greater, and its ability to attack others on your network is greater than it would be with only User privs. If the exploit happens to be written so that it requires admin privileges (as many do), just running as User stops it dead. But if you’re running as admin, an exploit can:

install kernel-mode rootkits and/or keyloggers (which can be close to impossible to detect)
install and start services
install ActiveX controls, including IE and shell add-ins (common with spyware and adware)
access data belonging to other users
cause code to run whenever anybody else logs on (including capturing passwords entered into the Ctrl-Alt-Del logon dialog)
replace OS and other program files with trojan horses
access LSA Secrets, including other sensitive account information, possibly including account info for domain accounts
disable/uninstall anti-virus
cover its tracks in the event log
render your machine unbootable
if your account is an administrator on other computers on the network, the malware gains admin control over those computers as well
and lots more

My #2 reason for running as non-admin applies to developers. Developing software as User instead of Admin helps ensure that your software will run correctly on end-users’ systems. Please, never again give me anything like Windows Messenger 4.x! An admin had to install it, of course, but no user could use it until that user ran it at least one time with admin privileges. That’s not even “an admin has to run it once before anyone else can”. That would have been bad enough, but Messenger actually required that each user run it with admin privileges. Completely inexcusable, and certainly attributable, at least in part, to devs running as admin. Keith Brown’s upcoming book also drives this point home really well. Some will argue that you should develop as admin and test as User. I don’t believe this works as well. Maybe I’ll drill down into that point in a future post.

My #3 reason applies just to Microsoft personnel, particularly those of us in customer-facing roles. Hey, y’all! We need to lead by example. People look to us for best practices, for the right way to do things. We are trying to convince the world that we are thought leaders in software and in software security. In the Unix world, they never run as root except when necessary. They “su”, do what they need to do, and revert back. We are not leaders when we run as root all the time. Comrades: you need to run as “User”, and your customers need to see you doing it. If you run into issues, don’t add yourself back to the admins group – file a bug against the offending product. Customers: if you see any MS sales, MCS, Premier, PSS, etc., doing web or email as admin, please tell them, “You’re not setting a very good example. I am disappointed.”

Next post we’ll start talking about how to run as non-admin without driving yourself crazy.

Not running as admin...

Aaron Margosis — Thu, 17 Jun 2004 09:13:00 GMT

The security principle of “least privilege” is well understood: Software should run with the smallest set of privileges needed to perform its tasks. Low-privileged processes can do a lot less damage when they are compromised (or just buggy) than processes running at high privilege levels. Windows has made great strides to run services with lower privilege than in the past. However, Windows users who are allowed to administer their own machines (including most Microsoft employees) usually run with Administrator privileges all the time. That is, the account with which they normally log on is a member of the local Administrators group (or worse, Domain Administrators). Everything they do, from reading email, browsing the internet, instant messaging, writing documents, and writing software, is performed with full (and unnecessary) administrative control over the entire computer. Email, web browsing, and instant messaging do not require administrative privileges, and are common avenues for malicious code to attack end users’ systems. To be more secure, users should log on with a Limited (or “Least-privileged”) User account (LUA), and use elevated privileges only for specific tasks that require them. Linux/Unix users have understood this for a long time, so this remains an area where Microsoft is perceived to lag in thought leadership. Unfortunately, Windows does not yet make running as non-admin as straightforward as it needs to be. Hopefully Longhorn will address these shortcomings. In the meantime, though, there are some neat workarounds that greatly mitigate the inconveniences.

In subsequent posts, my plan is first to try to convince you that running as non-admin is the right thing to do, to get you to want to run as a normal User instead of admin. Next, I'll offer up a collection of valuable tips, tricks and tools to make living as a Limited User as easy as possible.

In the meantime, let me know what your pain points are. Have you tried running as User? What were the biggest problems?