UAC – The Emperor’s New Clothes

I heard a complaint the other day about UAC – User Account Control – that was new to me.

Let’s face it, as a Security MVP, I hear a lot of complaints about UAC – not least from my wife, who isn’t happy with the idea that she can be logged on as an administrator, but she isn’t really an administrator until she specifically asks to be an administrator, and then specifically approves her request to become an administrator.

My wife is the kind of user that UAC was not written for. She’s a capable administrator (our home domain has redundant DCs, DHCP servers with non-overlapping scopes, and I could go on and on), and she doesn’t make the sort of mistakes that UAC is supposed to protect users from.

My wife also does not appreciate the sense that Microsoft is using the users as a fulcrum for providing leverage to change developers to writing code for non-admin users. She doesn’t believe that the vendors will change as a result of this, and the only effect will be that users get annoyed.

But not me.

I like UAC – I think it’s great that developers are finally being forced to think about how their software should work in the world of least privilege.

So, as you can imagine, I thought I’d heard just about every last complaint there is about UAC. But then a new one arrived in my inbox from a friend I’ll call Chris.

“Why should I pretend to be different people to use my own PC?”

I must admit, the question stunned me.

Obviously, what Chris is talking about is the idea that you are strongly “encouraged” (or “strong-armed”, if you prefer) by UAC to work in (at least) two different security contexts – the first, your regular user context, and the second, your administrator context.

Chris has a point – you’re one person, you shouldn’t have to pretend to be two. And it’s your computer, it should do what you tell it to. Those two are axiomatic, and I’m not about to argue with them – but it sounds like I should do, if I’m going to answer his question while still loving UAC.

No, I’m going to argue with his basic premise that user accounts correspond to individual people. They correspond more accurately – particularly in UAC – to clothing.

Windows before NT, or more accurately, not based on the NT line, had no separation between user contexts / accounts. Even the logon was a joke – prompted for user name and password, but if you hit Escape instead, you’d be logged on anyway. Windows 9x and ME, then, were the equivalent of being naked.

In Windows NT, and the versions derived from it, user contexts are separated from one another by a software wall, a “Security Boundary”. There were a couple of different levels of user access, the most common distinctions being between a Standard (or “Restricted”) User, a Power User, and an Administrator.

Most people want to be the Administrator. That’s the account with all the power, after all. And if they don’t want to be the Administrator, they’d like to be at least an administrator. There’s not really much difference between the two, but there’s a lot of difference between them and a Standard User.

Standard Users can’t set the clock back, they can’t clear logs out, they can’t do any number of things that might erase their tracks. Standard Users can’t install software for everyone on the system, they can’t update the operating system or its global settings, and they can’t run the Thomas the Tank Engine Print Studio. [One of those is a problem that needs fixing.]

So, really, a Standard User is much like the driver of a car, and an administrator is rather like the mechanic. I’ve often appealed to a different meme, and suggested that the administrator privilege should be called “janitor”, so as to make it less appealing – it really is all about being given the keys to the boiler room and the trash compactor.

It’s about wearing dungarees rather than your business suit.

You wear dungarees when working on the engine of your car, partly because you don’t want oil drops on your white shirt, but also partly so your tie doesn’t get wrapped around the spinning transmission and throttle you. You don’t wear the dungarees to work partly because you’d lose respect for the way you look, but also because you don’t want to spread that oil and grease around the office.

It’s not about pretending to be different people, it’s about wearing clothes suited to the task. An administrator account gives you carte blanche to mess with the system, and should only be used when you’re messing with the system (and under the assumption that you know what you’re doing!); a Standard User account prevents you from doing a lot of things, but the things you’re prevented from doing are basically those things that most users don’t actually have any need to do.

You’re not pretending to be a different person, you’re pretending to be a system administrator, rather than a user. Just like when I pretend to be a mechanic or a gardener, I put on my scungy jeans and stained and torn shirts, and when I pretend to be an employee, I dress a little smarter than that.

When you’re acting as a user, you should have user privileges, and when you’re acting as an administrator, you should have administrative privileges. We’ve gotten so used to wearing our dungarees to the board-room that we think they’re a business suit.

So while UAC prompts to provide a user account aren’t right for my wife (she’s in ‘dungarees-mode’ when it comes to computers), for most users, they’re a way to remind you that you’re about to enter the janitor’s secret domain.

5 thoughts on “UAC – The Emperor’s New Clothes”

  1. Neat idea, and I like the way you explain it. Somehow, the clothes metaphor doesn’t quite work for me though.

    Isn’t it simpler than that? The user and administrator accounts are associated with different roles, which may be filled by the same person at different times. You can think of your PC as your sitting room. Most of the time, you kick back and relax as a User, watching TV or editing a document. Sometimes, though, you need to do a bit of DIY, and that’s when you adopt a more serious Administrator outlook before messing with the wiring or plumbing.

    That’s pretty similar to your clothes metaphor, but it feels more immediate and personal to me. People are familiar with adopting different roles in “real life” – think of the difference between who you are at work and at home, as well as the example I’ve already given – so I think it’s OK to talk in terms of roles rather than clothes, so long as you can give non-IT examples.

  2. Sure – there’s a bunch of different metaphors, and yours probably fits the home user better.
    You don’t have exposed wiring, tools and plumbing in the bedroom. At least, not in most houses.
    If you talk to anyone in the identity field for any length of time you’ll find that they are frustrated with the inability of most people to grasp the concept that roles and identities are not mapped one-to-one onto individuals.
    The identity/role of “Alun Jones, who can manage his finances” is a shared one – my wife is able to control my finances. The identity/role of “Alun Jones, security d00d” at my workplace is one that I will give up as soon as I leave that company, and it will be replaced by someone else. There are several other shared, fungible and overlapping roles, which are very poorly modeled in the computer.

  3. Oh, and in case anyone’s concerned about the possibility that “The Emperor’s New Clothes” in the title is a metaphor trying to suggest that the user-to-user security boundary in Windows Vista is not really there, that’s not what I’m aiming for – far from it.
    That could have been said about Windows 95, 98, ME, and all the 16-bit versions of Windows, because there was no real division between users – they were merely convenient slots under which to associate preferences.
    In any NT-based operating system – Windows NT, Windows 2000, Windows XP, Windows 2003, Windows Vista, or Windows 2008 – there is a definite security boundary. Perhaps you could say it’s the Emperor’s New New Clothes – the ones he put on after he realised he was naked.

Leave a Reply

Your email address will not be published. Required fields are marked *