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.]
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:
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.
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 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?
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.
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:
But that last point is the cause of a big problem.
Here’s the sequence I have to deal with:
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:
(*) 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:
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.
[... 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.