May 23, 2006

LUA with UAC vs Least Privilege

So today I was talking with Eric about my previous post Microsoft... Eat your own UAC dogfood already!, when he asked me if running as an admin on Vista with LUA enabled count as least privilege in my mind. (I am paraphrasing... pipe up if I misunderstood the question Eric). It was a good question, and I thought it might be good to blog about the differences, especially as it relates to the security decisions that occur in Vista with the two scenarios. You see, they are actually different.

To me, least privilege means that you are given the privileges to accomplish your task/role/job. Nothing more. That's the whole point of the LEAST part. It is giving enough privilege to accomplish what you are deemed responsible to accomplish, and prevents you from doing things you aren't. When least privilege is rolled out properly, users won't even know they are using least privilege unless they do something they aren't supposed to do on the system. And that is the appropriate time to educate them on why they were not authorized to perform that function in the first place.

In Vista, LUA is Microsoft's first REAL attempt to minimize the required privileges to accomplish basic tasks in the system. Through UAC, a normal user cannot elevate their privileges without providing another credential. Today, we do that with runas or "Run with different credentials" or use some deep API to provide a secondary login to the security context we want. In Vista you get a new dialog prompt on a separate, secure desktop. That dialog will normally look and act different if you are a limited user or an admin.

If you are running as an administrator and make a request for a privileged operation, you get a dialog which offers you to make a security decision. It will ask you to make a decision to "Permit" or "Deny" the privilege elevation. If you are unsure, even though the default is now set to "Deny" (a good default choice), chances are you will just hit Permit. Why? How DARE a computer stop you from doing something. Problem is, there is no security challenge. I can't STOP you from hitting Permit. And with what we are seeing in the field, click fatigue has people just hitting Permit all the time. Not so good.

Now enter in a normal/limited user. That same action will show a different dialog box. It will require you to enter in the credentials of someone with authority to have the privilege. Oh no! You have to type a password in again. Fair enough complaint. But I would prefer to have to reenter a credential than simply cache it like OSX does... which leaves a possible attack vector if hostile code can wait for the elevation before running. Of course, Microsoft could make it easier by storing the credential in DPAPI and calling it up in the secure desktop.(Ya some work would be required to make that work properly... it's just a thought).

The point is that it is an entirely different chain of security decisions. As an administrator running UAC, you aren't challenged for your credentials when you need it most. When you run with a limited/normal user account... you are.

And that, to me, this is the difference between LUA with UAC and least privilege. A normal user can't do things they aren't supposed to do without making a concious security decision authorized by someone with required privilege. When logged in as administrator, you can. And knowing the weakest link in security is the human factor... a user running as administrator on a Vista machine is more likely to make a bad security decision than a normal user in this manner. And worst yet, people will associate the decision as a user problem! "You clicked on the dialog sir... you allowed it". UAC shouldn't absolve a software vendor of liability when it comes to privileges. They simply shouldn't need the privilege in the first place!

Just my opinion anyways. Fire away. Feel free to add your own comments if you think I am wrong.

Posted by SilverStr at May 23, 2006 02:11 PM | TrackBack
Comments

Dana, you make a good point, and I won't argue the point that using two accounts for normal vs. elevated privilege tasks may be better in some ways than using a single account. However, I think the "administrator-approval" mode (formerly called "protected admin" or "PA") is not as bad as you think.

First, even if you are using a single account, you can choose to be prompted for credentials rather than for simple consent - it's a configuration option. (The default is consent.)

Second, if you have the admin account password, it doesn't matter to the "consent/click fatigue" syndrome which account you're using - you will be prompted and the risk exists that if it happens a lot (it shouldn't) you won't pay attention anymore and automatically do whatever it's prompting you for in order to continue. If you don't have the admin password (the Standard User scenario), then it's a different story. But here we're talking about someone who is allowed to administer the machine, and Vista makes it *much* better than MakeMeAdmin does for XP.

Third, another improvement is that the consent/credential dialogs, and the apps that subsequently run, run at a higher integrity level and aren't subject to the kinds of "Shatter" attacks that are easy to mount in earlier systems. Caching a password with DPAPI won't offer that protection - any software running as the non-admin can decrypt that password and try to use it. (Note, though, that obtaining an admin password is not enough - things will not run elevated without going through the high-integrity UI gate.)

Posted by: Aaron Margosis at May 23, 2006 05:29 PM

Good points Aaron.

I guess I just don't like the idea of the "Secure by DEFAULT" decision to be to run as an administrator with "Prompt for consent" privileges, even if they are using protected admin. I would rather see the first user created to be a "Standard User" with the setting to "Prompt for Credential". Even having "Prompt for Credential" for admin may be enough here. I'm not sure.

Problem is, I KNOW people would be too pissed off to use that if they had to actually enter their credentials to elevate privileges. They are already turning things off when its set to consent. Imagine if they turned it on to ask for credentials!

Assuming Susan can figure out why domain joining Vista to an SBS box with /connectcomputer hangs, I am hoping that with the new Beta2 bits I have time to play with the User Account Control via group policy a bit more and see how I can make things bork. (Yes I know I can use secpol.msc without domain joining) Only then can I make an informed decision/comment on how well "administrator-approval" mode works if I set it to use credentials instead of consent.

Thanks for the great feedback!

Posted by: Dana Epp at May 23, 2006 05:56 PM

I have to say that my style of working fits with your comments to Aaron, Dana. I want to have a safe user access from initial bootup and configuration on to normal operation. I don't mind creating an administrator password as part of getting that going. Now, I basically know to do that anyhow, although it took a few OEM setup drills for me to get it right.

There are some other conditions and assistance that I'd like after tripping over my own shoe-strings a few times. (I forgot to lower my acount back to limited after changing the type to do some privileged stuff. I didn't figure that out until Windows Defender popped up with an unauthorized activity that should not even have come up.

So I could use some better failure modes around my own forgetfulness, and a much easier way to easily elevate privileges in some kind of confined way (like a separate process that takes its privileges to the grave when it dies). When I get my hands on the beta2 bits, I will see how much support there is for maintaining safe user operation in a smooth and less circuitous way.

Posted by: orcmid at May 24, 2006 01:06 AM

Dana, thanks for the feedback. I am a tech writer on the UAC team, and I just want to touch on the UAC defaults in Beta 2.

Account Creation during Setup: An admin account in Admin Approval Mode is created during setup. Any subsequent accounts are created as standard users by default. This is the default for home and enterprise.

New Installations: The built-in Administrator account is disabled by default on new installations.

Upgrades: On upgrades, if the built-in Administrator is the only active local administrator account, it is kept enabled and placed into Admin Approval Mode. If there is another active local administrator account on upgrade, the built-in Administrator account is disabled.

User Experience (UX) Defaults:
-Admin Approval Mode default UX - Prompt for consent.
-Standard user default UX - Prompt for credentials.

Posted by: Jennifer Allen at May 24, 2006 12:11 PM

The link to "Smashing the Stack" is dead. Apart from that, your LUA and UAC comments here have me rethinking some of the conventional wisdom that has trickled down to me from IT people over the years.

Tim

Posted by: Tim at May 24, 2006 01:19 PM

Re: Jennifer Allen

Hey,

so that means, like you wrote it here, if I do a clean installation of Windows Vista, the Admin account is disabled and I will automatically "forced" to log on into the standard user account with prompt for credentials..?!

This would be great, all other isn't fine!

thx in advance!

best regards,

PSchuetz

Posted by: PSchuetz at May 28, 2006 01:14 AM