The difference between liking and hating UAC?

Totally unscientifically, I have carried out a poll of people who like UAC (okay, a few security geeks like myself), and those who hate UAC – mostly my wife.

Something struck me as both a surprising common factor, and also a rather obvious explanation of why the two opinions are so polarised.

[Note for the pedants – yes, I’m using the term “UAC” here to mean “Elevation” – there are other portions of UAC that I’m not discussing, such as Protected Mode in Internet Explorer, and so on.]

We use UAC for different purposes


The UAC-lover seems to have ‘got least-privilege religion’ at least several years ago, and runs most of the time as a standard, restricted user. Most UAC-lovers do not seem to be “Administering the system all the time” types.

As a result, they use UAC as a means to elevate privilege on those occasions when they need to do something administrative, or when they need to run a program that has not yet been coded to run with least privilege.

When they’re doing something administrative, they’re comparing the UAC “Over-the-shoulder” (OTS) prompt against the methods that used to be available to them:

  1. Log off and back on – to do this, you have to close out all your applications, saving the documents you were working on, log off, log on as the administrator account, do the admin thing, log off, and log back on as your regular account.
  2. Fast User Switching (FUS) – not available on a domain, and anything but fast. The only advantage it has over logging out and back in is that you maintain your application state in the restricted user – the documents are still open, the programs are still running, etc.
  3. RunAs – this used to be how you elevate in Windows prior to Vista, but now you have to find another tool to do the same job for you, because RunAs won’t elevate your session even if you provide it with administrator credentials. [I use Jesper’s Elevate Explorer Tools from the Windows Server 2008 Security Resource Kit.]

Given these as alternatives, it’s no wonder that UAC and OTS elevation prompts are considered better.


The UAC-hater is fundamentally disinterested in least-privilege, at least as it applies to users. Least-privilege is an obvious and good programming strategy, a program shouldn’t ask for more privileges than it needs, but to this user, that’s something that the programmers should care about.

This user wants to be instantly, and automatically, elevated whenever she calls on a feature that would require it. This is how she’s used to running the computer, because she’s always called on to do administrative tasks – and she’s careful and knowledgeable enough to have avoided causing damage through doing so.

To this user, UAC is an impediment to that process – now, instead of merely running the administrative tool she wants, she has to ask to be allowed to run it as administrator.

With UAC set to automatically elevate for administrators, however, she’s far happier. Still not perfectly happy, because there are still occasions when she has to ask specifically to run elevated – when the program is capable of running as non-administrator, for instance. Such programs run as non-administrator by default, and don’t elevate themselves. These programs are irritating to such a user.

Typically, such programs appear to break when run with UAC disabled (or set to automatically elevate) – they fail to run, sometimes with bizarre error messages, often just crashing through failure to execute some action that the developers expected would succeed.

Other causes of breakage could be when an application is registered to a user, and the licence information is written to a file in the Program Files folder – when you’re running under UAC’s protection, files in the Program Files folder may be virtualised (i.e. the program thinks it’s accessing the file in the Program Files folder, but it’s really accessing a file in the user’s home directory tree), and when you’re running elevated, those same file accesses are not virtualised.

So, voila, instant loss of licence information, saved settings, or any number of other files that the program expected to find in Program Files.

What can we learn from this?

So, the message is clear – for installations with administrators who like the system to let them be administrators, don’t disable UAC, make UAC elevate silently for administrators instead.

This system works, too, for the restricted users. It allows them to operate as restricted users, except when they absolutely know they need to elevate. Over-the-shoulder elevation prompting is still available for them, should they need it.

What still needs to be fixed?

What this option doesn’t do is cover what appears to be Microsoft’s reason for creating the elevation prompts in the first place. Without UAC prompting at random points, the administrators in control of a system have no clear sign that they’ve just fired up “Mary Kate and Ashley’s Dance Party of the Century” only to be forced to run it as an administrator.

Even supposing you figure out that there’s a program you’re using which doesn’t adequately run in restricted user mode, or which doesn’t elevate itself where necessary, where can you go to get assistance from the developers of the application?

Call support?

Microsoft’s own support is an example of how off-putting such a process can be. Microsoft Money refused to update on one of our systems, and I eventually determined it was because the update needed to be elevated, but was expecting to find some files that were virtualised by UAC. It failed with a meaningless error message. To call support costs $25 for Microsoft to even pick up the phone – and if the support tech believes that this is an “advanced” issue, he may charge about ten times that much. Perhaps later, after they realise the problem is their own fault, Microsoft will refund you the money – but many small businesses and individual users don’t have that sort of money to loan to Microsoft, or other vendors.

So, is there any good way to persuade developers to quit their bone-headed “start with most privilege” behaviour? Maybe Visual Studio and compilation tools should refuse to run in an administrator session. Okay, so perhaps that’s not tenable, because there are development projects that do require you to be an administrator, because you’re developing something administrative – but what measure would make developers do the right thing for security (and for their users) naturally?

File and registry virtualisation appears to be a messy kludge on top of the sledge-hammer of UAC elevation, whose primary design goal appears to be to irritate end-users enough to persuade developers to stop doing the kind of things that requires virtualisation as a workaround, and the kind of things that requires administrator accounts in the first place.

Perhaps it’s time that, instead of kludging for these bad developers, Microsoft simply said “It stops. Now.” – if it’s not registered (at install time, or by manifest) as an administration tool, it doesn’t get administrative access – or virtualised access to HKLM or Program Files. Yes, that will mean admins will have two links to regedit, and similar tools – one to run in an administrator’s session, giving access to HKLM, another to run in their user’s session, giving access to HKCU.

CS-RCS Pro on Vista

I’ve been trying back and forth to get CS-RCS Pro, a version control suite, to work on Windows Vista.

I like CS-RCS Pro for a number of reasons:

  • Files stored in CS-RCS Pro are kept in a simple format, open and well-documented. As a result, if I ever have to move away from CS-RCS Pro (say, for instance, if they go out of business, or stop supporting it), I stand a good chance of reconstructing my versioning information completely in whatever product I move to, if only by re-creating files at each epoch and then checking them in to the new tool.
  • CS-RCS Pro integrates with Visual Studio. I can check files in and out while I’m editing them.
  • CS-RCS Pro integrates with Explorer, as a Shell Extension, so that you can right-click on source files, and check them in from there.
  • Of course, most important is that for single users, it’s free.

But that last point is the cause of a big problem.

Here’s the sequence I have to deal with:

  1. I have the single-user version of CS-RCS Pro.
  2. I use best practices for development of secure applications, particularly as regards running my software and my development tools as a restricted user unless it is strictly necessary to become an admin to test admin-level features, or to install / uninstall software or services, or to debug code that is running a different user context from my own.
  3. CS-RCS Pro insists that the user who installs it is also the user who runs it.
  4. CS-RCS Pro must be installed by an administrator.

I had originally intended to follow the appropriate installation practice for an enterprise application – that it should be installed by a recognised administrator, and then any post-install setup to customise for the end-user would be carried out by that end-user for themselves.

This didn’t work, as CS-RCS Pro configured the version control tree to be used by the administrative user, making it impossible for my restricted user to access the files.

I tried simply editing the ownerships and ACLs – that didn’t work – and then to additionally edit the configuration files, where it mentioned the name of my administrative user. That worked for a short while, but I noticed that every time I used MSTSC – Remote Console – also known as the Terminal Services Client – to access the system, the shell extension that CS-RCS Pro installs took up 100% CPU, and required that I restart Explorer. There are still a few applications that don’t work well when you kill Explorer from underneath them, and so this was somewhat of an untenable position.

Besides, this was an awful lot of effort to go through in order to get version control going.

Finally, it hit me how I should do this properly. It’s not clean and it’s not clever, and ComponentSoftware, the folks behind CS-RCS Pro, should consider how to change their installer to avoid this issue.

The simple five-step process is as follows – let’s say Wayne, an administrator, wants to install the software for Sharon, a restricted user:

  1. Wayne adds Sharon to the Local Administrators group on the machine to which Wayne will be installing CS-RCS Pro.
  2. Wayne logs on as Sharon (*)
  3. Wayne installs the application.
  4. Wayne logs off Sharon’s account.
  5. Wayne removes Sharon from the Local Administrators group.

(*) Note that asterisk – that’s the troubling part. Actually, step 1 is troubling too, but only because Sharon may have other processes trying to log in with elevated rights, should they ever be granted.

Step 2 requires either that Wayne allows his user, restricted though she is meant to be, to log on as an administrator – what if she quickly runs some tool that you don’t want her to run?

Okay, so you drag her away from the console immediately after she types her password – but what if she’s got startup items to add an administrative user on her behalf, or simply to stay in memory (as a service, say) and run with those enhanced privileges, to allow exploit later?

Alright, so what’s the safest way? The only good way I can think of is this:

  1. Wayne resets Sharon’s password.
  2. Wayne adds Sharon’s account to Local Administrators. Note that Sharon can’t log on at this point.
  3. From a command prompt in Wayne’s restricted user account, Wayne uses the runas command to execute the installation script in Sharon’s new administrative context. Runas reduces, and possibly eliminates, the chance that this administrative context will have the ability to run Sharon’s own code (unless the installation script does so).
  4. Wayne removes Sharon from the Local Administrators account.
  5. Wayne sets Sharon’s account to force a password change after the next logon.
  6. Wayne tells Sharon her new password.
  7. If this is not a domain environment, Sharon must change her password back to what it used to be, so that it is possible for her to access her protected data.

Some of you are probably reading this and wondering why I bother – after all, in many environments, developers insist on running as administrator all the time, because their development tools don’t support anything else.

Well, it’s time your developers – and their tools – grew up. Yes, I can quote, just as any other developer can, a number of cases where administrative access is required – although many developers actually get this wrong. You can run Visual Studio 2005 as a non-administrator. You can debug your own code running in your own logon session as a non-administrator.

Developers are very often the only people to run some sections of the code that they build, until it reaches the hands of the users. As such, developers need to spend as much time as possible, when they run their code, working in the same kind of user context as their users will have.

In general, developers should follow the same principle as other administrators – their day-to-day tasks (e-mail, web browsing, and yes, development) should be done in restricted user accounts; administrative user accounts should be available, but their use should be restricted to those operations which absolutely require administrative access, and those operations should be reviewed often enough to ensure that they need administrative access. Tools and environments grow and change, and a tool which yesterday required administrative access may run tomorrow without. LogonUser, for instance, used to require complete system access – today it can be called by any user.

Why you don’t run as root

[… or administrator, or whatever]

I like Roger Grimes, he’s a nice guy, and he generally makes me think about what he has to say. That’s a good thing, because otherwise he’d either be part of the same choir as me, or he’d be the sort of guy whose ideas I dismiss with a wave of the paw and a barely audible “Pah.”

Today, though, I think he’s missing something fundamental – and perhaps you are too.

He writes in the InfoWorld Security Adviser column that “UAC will not work”, on the simple basis that malware can still do all the things it wants to do without having to execute under a privileged account.

That’s true, and it always will be – the day that a computer can see my attempt to “delete the Johnson account, and forward that instruction to the following addresses”, and determine whether it’s malicious or appropriate, is the day when the computer can do the whole job for me, by simply choosing all possible actions and seeing which are malicious and which are appropriate.

However, what I can rely on, if the malware has been held out of privileged accounts, is the integrity of the system, and (unless they were prone to activating the same malware) the other users on that system. [By system, I may mean one machine or several networked together to perform a function.]

So while it’s true that the old cross-platform virus “forward this message to everyone in your address book, then delete all your data” is still going to function if the user stays out of administrator roles, at least the operation of the system can be restored, as well as whatever data has been backed up.

You don’t run as a restricted user to prevent viruses from happening – you run as a restricted user to prevent viruses from happening to the people and systems with whom you work. You run as a restricted user, so that when some system falls over, you can say “it couldn’t possibly have been me”. You run as a restricted user because if there is a bug in the program you run, its effects will be limited to only that portion of the OS and its data to which you are restricted.

Sure, least privilege is somewhat of an artificial construct – but the alternative is that users get more privileges than they need. That quickly boils down to “everyone can do anything”.

I’ve been on that kind of a network before, and when we found one guy’s stash of truly offensive porn (this wasn’t the occasional Rubens painting) on the server, we had no way of finding out who it was, let alone punishing them by firing them. The company I worked for was fortunate that whoever found it didn’t sue for fostering the creation of a hostile workplace.

So, no, UAC won’t stop malware – but then that’s not its purpose. It’s purely a beneficial, incidental, and temporary side-effect that it will stop much of today’s malware.