Chris Jackson's Semantic Consonance : UAC

Using the uiAccess attribute of requestedExecutionLevel to Improve Applications Providing Remote Control of the Desktop

Chris Jackson — Fri, 16 Oct 2009 01:47:04 GMT

I’ve run into this exact same problem 3 times now in one week, so I figure that probably doesn’t bode well and I should attempt to do something about it.

With 3 different pieces of software (one of them ours), the remote control functionality is imperfectly implemented. Let’s see if this sounds familiar to anyone. You are the helpdesk. You attempt to connect to a user’s desktop. You have to elevate an application. When you do, you (the helpdesk who actually has the password) doesn’t see the UAC dialog – instead, the end user (who does not have the password) does. Even if you decide to give the user the password (it happens), you then can’t control or even see the elevated application.

Kind of makes it hard to be a helpdesk when that happens.

Here are the 3 solutions that I have seen to this problem:

Do nothing. That’s what our solution did. It just failed every time elevation was involved.
Install a service. That’s what company X did. It requires the user to know an admin password, and that’s a problem for my customers
Run the application elevated. That’s what company Y did. It requires the user to know an admin password (a problem with my customers), and also won’t allow you to interact with any windows running at System integrity level (so an incomplete solution)

Here’s what I wish all 3 had done:

Manifest with uiAccess = true

Now, most people don’t really understand what this is for, and the UAC manifest is typically just a copy/paste affair. But it pays for the remote desktop developer to pay attention to it. For any regular piece of software, you generally want to stay away from it – it’s dangerous, and sidesteps a significant security feature (UIPI). But if you are remoting the desktop, it’s precisely what you want – you need to be able to see everything!

It’s dangerous enough, in fact, that we won’t allow you to set it without digitally signing your application. By default, you also have to have it installed in a secure location (such as Program Files). You can set a group policy to not require a secure location, but there is no option to not require a signature.

However, once set up, it’s really powerful. You’ll be able to remote every possible kind of window – any integrity level at all. No more blank, unresponsive screens. Everything comes across, regardless of integrity level.

You’ll also be able to leverage the group policy that lets you prompt NOT on the secure desktop if you are a UIAccess application – that way you don’t have to lose the defense in depth of using the secure desktop for normal elevation, but you also avoid writing code to remote the secure desktop when your remote desktop application is running.

All in all, you are just full of win.

Now, it’s my job to fix up apps that are written suboptimally, so you may be wondering how I did getting these working?

Our application, rather conveniently, used an external manifest. All I had to do was open up the manifest in Notepad, and type four characters (t-r-u-e) in the uiAccess attribute. Done. Now it works great. (Of course, everyone who downloads it will download a new broken one, so they’ll have to text edit it too – clearly we want to work with the team that makes this to fix it on their end, but you aren’t stuck – you can fix it without depending on anyone else.)
Company x, the one that used a service (claiming of course that it was UACs fault that they had to do this)? I can’t fix it. They used an internal manifest, which has precedence over any external one I might lay down there. I could extract that manifest with mt.exe, edit it, and then re-inject it, but then I invalidate the digital signature. Remember that this is a non-optional requirement for a uiAccess app! So, there is nothing I can do. I’m trying to contact the vendor.
Company y, the one that elevates to admin – this one I didn’t have time to examine – they do a “just in time” install and uninstall, so I couldn’t explore the manifest, but since it’s so transitive it’d be hard for me to do much anyway that would last.

Anyone writing desktop remoting applications, please consider using this. And feel free to contact me if you have questions. I would be delighted to help you.

For the record, here is the corrected manifest for the one I was able to fix:

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1'
manifestVersion='1.0'>
<assemblyIdentity
   version="1.0.0.0"
   processorArchitecture="X86"
   name="Microsoft.FixedUpApp.SupportConsole"
   type="win32"
/>
<description>Fixed Up App</description>
    <dependency>
      <dependentAssembly>
        <assemblyIdentity type='win32'
         name='Microsoft.Windows.Common-Controls'
         version='6.0.0.0'
         processorArchitecture='x86'
         publicKeyToken='6595b64144ccf1df'
         language='*'
        />
      </dependentAssembly>
    </dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker"
         uiAccess="true"/>
      </requestedPrivileges>
    </security>
</trustInfo>
</assembly>

Understanding the AdditiveRunAsHighest Flag on Windows 7

Chris Jackson — Thu, 08 Oct 2009 23:32:35 GMT

This post corrects an error from a previous post.

Back when I was explaining the changes in the operating system layers for Windows 7, I incorrectly described the AdditiveRunAsHighest. Since RunAsHighest is already confusing enough, and AdditiveRunAsHighest is even more confusing (even I got it wrong), I want to make sure I actually get it right (and apologize for not having done so before).

AdditiveRunAsHighest requests that the application receives the RunAsHighest flag if and only if nobody else has requested a higher level of elevation.

That means we will overrule a manifest if that manifest is asInvoker, but we will not overrule a manifest if that manifest is requireAdministrator. It also means we will overrule a layer if that layer requests RunAsInvoker, but we will not overrule a layer if that layer requests RunAsAdministrator.

In short, it means that this flag will only be used to increase your level of elevation (to highestAvailable) and will never be used to decrease it (from requireAdministrator).

The reason why this flag exists? Setups. If we think you are a setup, then the setup detection logic applies the VistaSetup layer, which has (as you might imagine) RunAsAdministrator. We don’t want setups to fail for every standard user out there – they still need to prompt. So, this layer will not cause standard users to stop seeing prompts for setups (or manifested apps for that matter). If we had used the existing RunAsHighest flag, then it would have broken setup detection for standard users – and we love our standard users.

The Curious Case of the Redundant UAC Policies

Chris Jackson — Tue, 06 Oct 2009 23:22:52 GMT

One of the unfortunate consequences of actually having to ship your software at some point is that you have to make some compromises along the way. The decisions you make can vary based on the time you are called upon to make them. As frustrating as that is for somebody who is trying to understand the system by trying to reverse how we make decisions, it remains a fact of life.

Case in point: for anybody who has explored the updates to the User Account Control (UAC) policies on Windows 7, you may have noticed that there are multiple policies which appear to govern the exact same thing.

In fact, they do govern the exact same thing.

User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode has the following options:

Elevate Without Prompting
Prompt for credentials on the secure desktop
Prompt for consent on the secure desktop
Prompt for credentials
Prompt for consent
Prompt for consent for non-Windows binaries (default)

User Account Control: Behavior of the elevation prompt for standard users has the following options:

Automatically deny elevation requests
Prompt for credentials on the secure desktop
Prompt for credentials (default)

At the same time, you’ll find a policy that configures the secure desktop:

User Account Control: Switch to the secure desktop when prompting for elevation (enabled by default)

What’s going on here – aren’t these directly overlapping?

Well, first let’s help you sort out how to use the policies, next we’ll explain why there are two ways to configure the same thing, and finally we’ll chart out the outcome to give you the easy answers.

A configuration request to use the secure desktop always wins. Whether you configure the admin policy, the standard user policy, or the secure desktop policy, any vote for the secure desktop will cause Windows to use the secure desktop.

So, what happened?

While we were re-doing UAC to make it “less prompty” for Windows 7, we were changing a number of things. We added the ability to exclude Windows binaries. We added a slider instead of an on-off switch. While you are mucking around anyway, you may think, “what if I wanted to have different secure desktop behavior for my standard users than I do for my administrators?” You can’t with only one policy. And it doesn’t take that much additional effort to add a couple of additional options. But you’ll note that there is no secure desktop option for Prompt for consent for non-Windows binaries.

We’d left the secure desktop policy there for application compatibility reasons, but we didn’t use it.

So, we’re happily moving along, when we eventually noticed that there were some accessibility issues in some scenarios when not using the secure desktop, so we needed to have an option to make the “less prompty, but on the secure desktop” setting which, as you can see, doesn’t exist.

Now, if you think about it as if it were your own software, how long would it take you to fix it? It’d take you no time at all to add a new option to the dropdown. You can probably come up with a very easy way to implement the change in consent.exe for reading that policy as well.

But Windows is a complex place. That’s not all you’d have to do. What about the customer experience improvement program? You have a finite, already defined amount of room to feed back all of your configuration and data here. If you change your compression algorithm to incorporate this new option, then you impact all kinds of teams. Could you do it? Sure. But it was at a point in the process when you stop making “blue sky” designs that are the best implementation, and instead fall in the category of “do the minimal change necessary to achieve the required goals”. Architectural changes late in the process aren’t going to win if there are other alternatives. The fastest way was to start using the existing secure desktop policy again. So we did. Better that than to delay shipping.

So, here’s what your secure desktop behavior will be, depending on configuration:

Acct. Type	Account Elevation Policy	Secure Desktop Policy	Secure Desktop Used?
Administrator	Elevate Without Prompting	Enabled	n/a
Administrator	Prompt for credentials on the secure desktop	Enabled	Yes
Administrator	Prompt for consent on the secure desktop	Enabled	Yes
Administrator	Prompt for credentials	Enabled	Yes
Administrator	Prompt for consent	Enabled	Yes
Administrator	Prompt for consent for non-Windows binaries	Enabled	Yes
Administrator	Elevate Without Prompting	Disabled	n/a
Administrator	Prompt for credentials on the secure desktop	Disabled	Yes
Administrator	Prompt for consent on the secure desktop	Disabled	Yes
Administrator	Prompt for credentials	Disabled	No
Administrator	Prompt for consent	Disabled	No
Administrator	Prompt for consent for non-Windows binaries	Disabled	No
Standard User	Automatically deny elevation requests	Enabled	n/a
Standard User	Prompt for credentials on the secure desktop	Enabled	Yes
Standard User	Prompt for credentials	Enabled	Yes
Standard User	Automatically deny elevation requests	Disabled	n/a
Standard User	Prompt for credentials on the secure desktop	Disabled	Yes
Standard User	Prompt for credentials	Disabled	No

How to Run Applications Manifested as HighestAvailable With a Logon Script Without Elevation for Members of the Administrators Group

Chris Jackson — Sun, 13 Sep 2009 18:22:51 GMT

Updated 17-Sept-2009

My friend Aaron has been trying to post a comment with his recommendation. However, it never, never, ever shows up because apparently we either don’t buy good software for our blogging system, or else the software has a personal vendetta from him (perhaps it’s angry at him for not posting often enough himself). But his comment is worthwhile, so here it is:

Rather than use that undocumented (and unsupported) environment variable, why not just change the "regedit" invocation to "REG.EXE IMPORT"? REG.EXE doesn't demand elevation -- it's manifested "asInvoker", and can import .reg files...

Here’s a trick I used to help out a customer:

My customer was using a logon script to set some per-user registry keys when the user logged in. This worked fine for their standard users on Windows XP, and it also worked fine for their standard users on Windows 7. However, it added an extra prompt for the few folks who had exceptions to be members of the Administrators group.

You see, they were using regedit.exe to import a .reg file. And, even though they didn’t need administrator privileges to edit the parts of the registry they wanted to modify, the entire application is manifested as highestAvailable, so it would always prompt for their administrators.

So I cooked up the following .bat file to achieve the same thing without annoying their administrators:

set __COMPAT_LAYER=RunAsInvoker
start regedit.exe

And they were off to the races.

Was there another way? Perhaps. But this let them keep their existing scripts and only have to add a single line at the front, so it was the path of least resistance.

Why Do Some Operating System Modes Include AdditiveRunAsHighest While Others Do Not?

Chris Jackson — Fri, 21 Aug 2009 00:54:20 GMT

A little while back, those of us who explain application compatibility for a living and try to help people get their arms around it ran up against those who implement it in the product on the scale of … the whole earth.

Those of us who explain things for a living really prefer (really, really prefer) when the system is internally consistent, because that makes it easier to explain.

Those who build systems really work to make the investments they can, with finite resources, to fix the greatest percentage of applications they can.

And sometimes those goals are not in alignment.

Case in point: remember back in April when i was talking about how we added the new AdditiveRunAsHighest shim to our operating system layers? Well, it turns out that we didn’t touch quite all of them. The following layers have AdditiveRunAsHighest applied:

Win95
Win98
WinXP
WinXPSP1
WinXPSP2
WinXPSP3

The following layers do not have it applied:

NT4SP5
Win2000
Win2000SP2
Win2000SP3
WinSrv03
WinSrv03SP1
VistaRTM
VistaSP1
VistaSP2
WinSrv08SP1

What’s the rhyme or reason here? Well, you can start to tease out some logical ones. First, most people don’t use compatibility modes on server apps. (They may use them on a server, such as when you use terminal services apps, but if you have a high-throughput server application, shimming it up and running it unsupported is probably not high on your list of acceptable mitigations. So, remove Server 2003 and Server 2008. Next, if it worked on Windows Vista, it has already seen UAC, so we don’t really need to have it there. But … what about NT4 and Windows 2000? If those were included, couldn’t we just say, “ever client operating system prior to Windows Vista includes this shim”?

Yes, we could.

And wouldn’t the same arguments that made sense for the other ones make sense here?

Yes, they would.

So, what gives?

Well, in the game of probability (fix the most apps), internal consistency was not the focus. Fixing the largest number of apps was. And there simply were not enough apps that needed the Windows NT 4 and Windows 2000 modes to bring it on the radar that they needed them too. And those of us who do explain these things for a living didn’t notice it until July, when the bug bar was way too high to get this fix in (since it doesn’t actually block you from getting things done, it just makes it harder to explain why the system behaves the way it does).

So, instead of a nice, logical rule, you have a list to memorize. 95, 98, and XP get AdditiveRunAsHighest. Everything else does not. Sorry for making you memorize a list – I’d much rather you were memorizing rules that you could logically explain, but so it goes.

Changes to the Operating System Layers (Compatibility Modes) in Windows 7

Chris Jackson — Wed, 29 Apr 2009 02:19:47 GMT

It’s visible in the beta, but I haven’t heard a lot of people talking about this externally. Regardless, I wanted to shed some light on what happened, and add a bit of the human perspective behind the decision.

If you inspect the operating system layers (called Compatibility Modes in Compatibility Administrator), you’ll find that they contain an important new entry: AdditiveRunAsHighest. Let’s explore this a bit, because it’s pretty important what it does.

RunAsHighest

First and foremost, AdditiveRunAsHighest is RunAsHighest. (We’ll get to the Additive part in a bit.) It’s an incredibly confusing elevation flag for many folks. It basically means that, if you have the ability to elevate to a higher token, then please do. Otherwise, just stay where you are. That means, if you’re a member of the Administrators group with UAC turned on, and you’re not currently running elevated, you’ll see a prompt. If you are a standard user, you will not. If you have the SeLoadDriver privilege in your token but would otherwise be a standard user, we’ll still split your token, and if you provide the same credentials, we’ll elevate to a token that contains that privilege. (You can’t think too black and white about elevation – not everyone is cleanly either an admin or a standard user.)

I say that it’s confusing because most people don’t fully grok that. Most people, rather, believe that MMC.exe requires being an admin, and that’s why it prompts. It doesn’t require it, you just happen to have a more privileged token available so it’s going to try to use it. If you were running as a standard user, you wouldn’t see a prompt!

OK, so we’re off to a good start – the new shim is related to the most confusing elevation flag we’ve got. How have we made that more interesting?

AdditiveRunAsHighest

If you’re an IT Pro, you’ll like this: you always get to win. You see, a developer can specify, in the XML manifest for an application, the run level for that application. But you, as the IT Pro, get to overrule that. If you think the developer made a bad call with their specified run level, just specify what you think, and you’ll win.

But AdditiveRunAsHighest means that you only care to vote if the developer didn’t. So, if you find a manifest specifying run level, you’re voting to take what they asked for. If not, then you are asking for RunAsHighest.

(I guess I find that a little curious because, if you know enough about Windows Vista to add a runlevel to the manifest, it’s not entirely clear why you would need an XP or earlier shim, but so it goes.)

Putting it all together

What this basically means is that, if you were running as a standard user, and you didn’t work, the RunAsHighest will leave you as a standard user, and unless file/registry virt fixes you, you’re still broken. No regression. But, if you were previously a full admin, and now you’re a protected admin, you’ll prompt to get back to full admin, and away you go.

If only it were that simple. But, realistically, nobody is super happy with this outcome. This doesn’t represent what we wanted to do, it represents what we could do in the parameters we were given (which included, of course, the parameter of, “we have to ship an operating system”).

Elevation fixes ~20% of broken applications that used to work on XP

There are truths, half-truths, and statistics. This is a statistic. That’s the bright side. The down side is that the other 80% of applications aren’t fixed by elevation (actually it’s more like 50% when you incorporate this PLUS other fixes in the layer, so that’s a little unfair of me), yet they are prompting you anyway! But, in the absence of other alternatives, it was decided that people are more annoyed by apps not working than they are by prompts. Oh yeah, we know you’re still annoyed by prompts – we just think you’re more annoyed by broken apps.

And, when it came down to it, even if the number of apps fixed were 10%, it would have been a no-brainer for the team. Broken apps are a serious downer.

What does it mean for me?

Well, if you’ve built up a custom shim database that contains operating system emulation layers, their behavior is going to change. You may want to edit them. I typically recommend that you chose only the specific shims that you need, rather than taking a whole layer, and I’d just go that route.

If you’re fiddling with the compatibility tab, it means you’re going to get more prompts.

Several Program Compatibility Assistant scenarios lead to the XPSP2 layer, which will mean more prompts even if you don’t get geeky on us.

It also could mean that more apps work, if you are a consumer with little knowledge of elevation, tokens, administrators, or any of that garbage, and just want your apps to work. That’s who we’re really targeting with this. Someone advanced enough to find the compatibility tab (or lucky enough to have PCA suggest fixing something) but not advanced enough to be reading this and looking to become a shim ninja.

What we would rather do

Like I said, this was a trade-off. And, honestly, a few folks were pretty up in arms about this (and I count myself among them) until we finally got people to stop suggesting that this was a solution people actually were quite fond of and shouldn’t we just drink the kool-aid and believe that it truly was good for us, and instead fess up that they fought it themselves but just couldn’t get it done in the ideal way so had to find the best compromise for the non-ideal choices that lay before them.

We’d rather have a quick, automated way to put in a targeted fix that didn’t mean “keep running as admin” and instead did something less reckless. But that’s hard to do. (Aaron Margosis seems like he’s coming pretty darned close, though – just give him time.)

If we’re going to elevate, we’d like to have a way to kill the prompts somehow. (Aaron won’t be so fond of that one.)

In the end, it’s all a balancing act. Unlike milk, software doesn’t go bad. You shouldn’t have to go buy a new version of something until it offers features that make you happy (or, these days, until you can afford it). But how do we move the software ecosystem forward, without making you pay the price?

I keep saying this, I know, but it keeps being true: app compat is hard.

The Secret to Power App Compat Debugging

Chris Jackson — Thu, 16 Apr 2009 22:57:44 GMT

If you come to me for advice about how to become a debugger, chances are that I’m going to give you a couple of must-read reference books, an then tell you to start paying attention. Because, unless you’re drastically more lucky than I am, stuff is probably breaking on you all the time. While a lot of problems just go away, if you let it just go away, you’ve just squandered an opportunity to debug something.

The only way to become a master at debugging is to practice. A lot.

But there’s a level even above master debugger – being somebody able to get to the bottom of most every issue (eventually – hey, even for the best, it can take time, lots and lots of time). What’s that level? The Power Debugger. Somebody who dispenses with the need for time, and just fixes things quickly because there is no alternative.

How do you reach that level?

Simple.

Have a 4-year-old.

Four year olds don’t care about the challenges application compatibility. They just want their games to work, and they are quite vocal when they don’t. They look at you thinking, “why can’t you fix this? Aren’t you supposed to be able to do this? Can’t you see this is bothering me?” Oh, and then the cry. And yell. And cry. Great.

Fortunately, the solution for pre-school games is typically rather easy. For reasons that are completely beyond comprehension to me, it turns out that many developers of games for pre-schoolers assume that I want my 4-year-old to be an administrator on my computer.

RunAsAdmin, and we were on our way. Optimal solution? No. But you have to power debug with a 4-year-old.

So that leads me to this:

If you develop commercial games for pre-schoolers, I will help you debug your application so it works for standard users for free. But you have to promise to run your developer workstation either as a standard user, or as a protected administrator (that’s right, turn UAC back on) on Windows Vista or later.

Every application should run as a standard user. But games for children should have run for standard users even on XP.

Standard User Analyzer Refuses to Run with Application Verifier 4.0 (and Application Verifier 3.x is Gone!)

Chris Jackson — Wed, 04 Feb 2009 21:01:00 GMT

Updated March 16, 2009: Somebody updated these links with the 4.0 version (which kind of defeats the purpose of having these links so I’m not sure what they were thinking) but they’re back to the 3.x version now.

Hey, there’s a new version of Application Verifier in town, and guess what? Standard User Analyzer doesn’t like it. ACT 5.0.3 (the latest publicly available version) is hard coded to look for versions 3.2 through 3.5, so the brand new version 4.0 kind of leaves this tool in a lurch.

It’s also a mystery to me why the #1 web hit on live.com for Application Verifier leads to http://www.microsoft.com/downloads/details.aspx?FamilyID=bd02c19c-1250-433c-8c1b-2619bd93b3a2&DisplayLang=en, which is a, “We are sorry, the page you requested cannot be found” page, which helpfully has search results from the same search engine, which helpfully has a #1 web hit of the same unhelpful page. Seriously? Did we just not pay attention to the fact that we should have kept this page and forwarded, since people don’t want to have to guess the GUID for the new version? A search for Application Verifier 4.0 brings up the desired download as the #2 hit, so all is not lost (just most).

But the fact that you can eventually find this incredibly useful and important tool if you try hard enough still doesn’t help fans of Standard User Analyzer (which are many). So, until we release ACT 5.5 (which support Application Verifier 4.0), we posted the 3.x versions again in a super-secret hidden location so you can still download them from us instead of from a random source. Unfortunately, we didn’t include fwlinks in the product so we could just update these links and you wouldn’t have to read this here, an omission we have already fixed.

So, here’s where you can get the 3.x versions of application verifier:

http://msdl.microsoft.com/download/symbols/debuggers/Private/ApplicationVerifier.ia64.msi

http://msdl.microsoft.com/download/symbols/debuggers/Private/ApplicationVerifier.amd64.msi

http://msdl.microsoft.com/download/symbols/debuggers/Private/ApplicationVerifier.x86.msi

Note that you really shouldn’t use Application Verifier 3.x on Windows 7 – you’ll want to use Application Verifier 4.x on it, which means you’ll end up waiting for ACT 5.5 to use SUA on Windows 7.

Helpdesk Elevation on Windows Vista and Windows 7

Chris Jackson — Thu, 08 Jan 2009 21:42:50 GMT

Since I was talking about configuring UAC on Windows Vista and Windows 7 a bit yesterday, I thought it made sense to bring up another policy whose actual use may not be obvious based on the name.

User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop

We talked about the secure desktop – but what is this UIAccess all about? Well, you can get details here:

http://msdn.microsoft.com/en-us/library/ms742884.aspx

But rather than going deep, let’s look at the manifest for msra.exe (Microsoft Remote Assistance):

sigcheck -m c:\windows\System32\msra.exe

sigcheck v1.54 - sigcheck
Copyright (C) 2004-2008 Mark Russinovich
Sysinternals - www.sysinternals.com

"c:\windows\system32\msra.exe":
        Verified:       Unsigned
        File date:      11:47 PM 12/12/2008
        Publisher:      Microsoft Corporation
        Description:    Windows Remote Assistance
        Product:        Microsoft« Windows« Operating System
        Version:        6.1.7000.0
        File version:   6.1.7000.0 (winmain_win7beta.081212-1400)
        Manifest:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv3="urn:schemas-micr
osoft-com:asm.v3" manifestVersion="1.0">
    <assemblyIdentity
        version="5.1.0.0"
        processorArchitecture="amd64"
        name="Microsoft.Windows.RemoteAssistance"
        type="win32"
    />

<description>Remote Assistance</description>

I think of this policy as the “give helpdesk the ability to elevate” policy.

(Obviously this only works if you don’t configure the policy to auto-deny elevation requests by standard users.)

The Windows 7 UAC Slider, and What You Can Do on Windows Vista Today

Chris Jackson — Wed, 07 Jan 2009 22:51:04 GMT

As I am focusing more and more on Windows 7, I find that blogging now begins with web searching, to make sure that what I’m talking about is already publicly disclosed and, as such, I’m not putting my job at risk. :-)

I want to go into a bit of detail on UAC configuration, what’s changing in Windows 7, and what’s available today. Because, in my experience, there are a lot of people who don’t fully understand how to configure UAC as it exists in Windows Vista – probably because we haven’t spent enough time talking about it.

PC Magazine (oh, how I’m going to miss the dead tree edition of that magazine) was kind enough to already show you what I want to talk about in it’s article here: http://www.pcmag.com/article2/0,2817,2335122,00.asp. So, let’s have a second look at the new UI for UAC in Windows 7, as it exists today (this is not a commitment that it will never change, that it’s a good idea, or that you won’t experience premature hair loss from viewing the picture – all the regular disclaimers for pre-release software apply):

Now, my friend Crispin would prefer a different UI metaphor than a slider – he’d like to see a pair of pants – the further down you pull the slider, the further down your pants are while you’re computing. I actually think that’s a really good analogy. Let’s look at each of these settings, talk about what you can (and can’t) do on Windows Vista today, and then add some commentary on the consequences of making that choice.

Always Notify Me

This is UAC configured the way you get it on Windows Vista today. This one should be very familiar.

Notify me only when programs try to make changes to my computer

This one is genuinely new for Windows 7, and essentially will auto-approve elevation when performing some actions to modify system state. I won’t get into the mechanics of exactly what we’re doing, because it’s neither final nor am I currently authoritative on all of the details behind the logic here. My goal here is to explain what you could do today, anyway.

Notify me only when programs try to make changes to my computer (do not dim my desktop)

Well, half of this (as discussed above) is new stuff, but the other half (the half in parentheses) is available for you on Windows Vista: not dimming the desktop. That’s something you can configure today. In group policy, under Windows Settings \ Security Settings \ Local Policies \ Security Options, you’ll find an entry called User Account Control: Switch to the secure desktop when prompting for elevation. Change that policy to disabled, and you have that half of the configuration.

Why do we default to switching to the secure desktop? Defense in depth. Message queues don’t have security descriptors. Of course, User Interface Privilege Isolation should help keep less trusted messages from getting to the approval dialog (consent.exe runs with System IL), but it’s even better to get to a separate desktop since the boundary of a window message is the desktop.

You see, today Windows doesn’t have what some call “Authentic User Gestures” – the ability to differentiate between a real user clicking a mouse button which gets translated into a window message to click the button, and an application sending a window message to pretend that somebody clicked it. To the receiving application, they both look exactly the same. So we build up mechanisms like this. While elevation is not technically a security boundary, it should at least do a reasonably good job of looking after you.

When do I see people configuring this policy? Well, there were some drivers early on that had a really hard time with the transition to the secure desktop (I haven’t seen this in a while). And otherwise, I see people configure this temporarily to make it easier to grab a screenshot of the dialog box. (Of course, if you want to make it look more realistic, you should change the theme to the basic theme first, since the secure desktop doesn’t have glass.

Never notify me

This is the off switch that you have in Windows Vista. This is bad for all the same reasons that it’s bad in Windows Vista.

So, what’s really new is the “windows settings” categorization. But wait, there’s more! This slider still doesn’t expose two settings which are very interesting to know about!

In the “Behavior of the elevation prompt for …” settings you have:

(For local administrators) Elevate without prompting

This is the setting for people who never, ever want to see a prompt, but don’t want to lose out on the value of UAC. You keep things like Internet Explorer in Protected Mode, AXIS for your standard users, UAC file and registry virtualization, and all kinds of other useful stuff – and, oh yeah, the fact that the overwhelming majority of software testing is done in the default configuration (enabled). If you’re hell-bent on disabling UAC, could I talk you into giving this setting a try?

(For standard users) Automatically deny elevation requests

This is the setting for people who disable UAC for their standard users because they don’t want them seeing a credential prompt, since their users won’t have credentials and, in the enterprise, that just means it’s going to cost more to run the helpdesk. You don’t have to disable UAC and lose all of its benefits, you just need to tweak this policy.

Personally, I’d like to see an additional notch in the slider that uses these settings – leaving UAC on but getting rid of all notifications. Perhaps even hiding to “off” switch a bit, because in my travels, this is the setting that gives the best overall experience for people who hate prompts passionately. But alas, it’s not my decision to make.

By the way, here is the e7 post on UAC: http://blogs.msdn.com/e7/archive/2008/10/08/user-account-control.aspx

Why don’t elevated applications receive environment variables set by non-elevated calling process?

Chris Jackson — Wed, 29 Oct 2008 19:00:36 GMT

I had a conversation with a customer (via email) the other day, and I wanted to to into a bit of detail here explaining what is going on.

Essentially, the customer was attempting to pass information to another application while launching it using environment variables, and it wasn’t working. Of course, it used to work, and it was confusing that it didn’t. Particularly since this failure seems to contradict the following statement directly from the SDK: “By default, a child process inherits a copy of the environment block of the parent process.”

The launching process was not elevated, but the target process was.

I recommended using command lines instead, but wanted to illustrate what is happening here. To see it for yourself, you can create the following two programs:

elevation_launcher.cpp

#include <windows.h>
#include <shellapi.h>

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd) {

    UNREFERENCED_PARAMETER(hInstance);
    UNREFERENCED_PARAMETER(hPrevInstance);
    UNREFERENCED_PARAMETER(lpCmdLine);
    UNREFERENCED_PARAMETER(nShowCmd);

    // Configure the process to launch
    SHELLEXECUTEINFO sei = { sizeof(SHELLEXECUTEINFO) };
    sei.lpFile = TEXT("Elevation Target.exe");
    sei.nShow = SW_SHOWNORMAL;

// Attempt to pass data using environment variables
SetEnvironmentVariable(TEXT("FromParent"), TEXT("Passed using environment variable"));

    // Attempt to pass data using the command line
    TCHAR szCommandLine[] = TEXT("\"Passed using command line\"");
    sei.lpParameters = szCommandLine;

    // Launch the child app
    if (!ShellExecuteEx(&sei)) {
        DWORD dwStatus = GetLastError();
        // ... handle the error
    } else {
        // ... handle the success
    }
    return 0;
}

elevation_target.cpp

#include <windows.h>

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd) {

    UNREFERENCED_PARAMETER(hInstance);
    UNREFERENCED_PARAMETER(hPrevInstance);
    UNREFERENCED_PARAMETER(lpCmdLine);
    UNREFERENCED_PARAMETER(nShowCmd);

    // Retrieve and display the parameter passed using environment variables
    PTSTR pszValue = NULL;
    DWORD dwResult = GetEnvironmentVariable(TEXT("FromParent"), pszValue, 0);
    if (dwResult != 0) {
        DWORD size = dwResult * sizeof(TCHAR);
        pszValue = (PTSTR)malloc(size);
        GetEnvironmentVariable(TEXT("FromParent"), pszValue, size);
        MessageBox(NULL, pszValue, TEXT("Environment Variable"), MB_OK | MB_ICONINFORMATION);
        free(pszValue);
    } else {
        MessageBox(NULL, TEXT("The environment variable was not found"), TEXT("Environment Variable"), MB_OK | MB_ICONERROR);
    }

    // Retrieve and display the parameter passed using the command line
    int nNumArgs;
    PWSTR *ppArgv = CommandLineToArgvW(GetCommandLine(), &nNumArgs);
    if (nNumArgs > 1) {
        MessageBox(NULL, ppArgv[1], TEXT("Command Line"), MB_OK | MB_ICONINFORMATION);
    } else {
        MessageBox(NULL, TEXT("The command line was not found"), TEXT("Command Line"), MB_OK | MB_ICONERROR);
    }
    HeapFree(GetProcessHeap(), 0, ppArgv);

return 0;

}

Now, if you manifest both files with an asInvoker reference, both pieces of data are sent to the child process – the environment variable, and the command line. However, if you manifest elevation_target as requireAdministrator, leaving elevation_launcher as asInvoker, you still get the command line, but you lose the environment variable.

Huh?

To understand what is going on, you have to understand that, when you elevate, the application, you aren’t actually the parent. Rather, the shell calls into the Application Information Service. This service calls consent.exe, which is what prompts for elevation. Assuming the request is approved, the service then uses the linked elevated token and calls CreateProcessAsUser using the linked token.

So, the Application Information Service is the parent of the elevated process, not the process that called ShellExecute(Ex). And the elevated process inherits that environment block.

Of course, it confuses things somewhat that we then reparent the process so it looks like the launching process is the actual parent if you look at the process tree using a tool such as Process Explorer.

Per-User COM Registrations and Elevated Processes with UAC on Windows Vista SP1 Part 2: OLE Automation

Chris Jackson — Tue, 22 Jul 2008 19:29:46 GMT

Here's an interesting lesson which, quite honestly, I haven't thought about for a while. But it turns out it's rather important.

A little over a month ago, I talked about a change to Windows Vista in SP1 regarding per-user COM registration, indicating that we changed the behavior and it would now work with UAC disabled. Let's dissect how this is implemented specifically. First, I disassembled the function, and then I focused in on the CALL instructions, to find:

0:010> uf ole32!OpenClassesRootKeyExW
251 760878ba e888ffffff      call    ole32!RegHelpSuspendImpersonate (76087847)
257 760878c5 ff15e4110676    call    dword ptr [ole32!_imp__GetCurrentProcess (760611e4)]
257 760878cc ff159c160676    call    dword ptr [ole32!_imp__OpenProcessToken (7606169c)]
261 760878e1 e8c9000000      call    ole32!IsUserHiveOK (760879af)
265 760878fd ff1554160676    call    dword ptr [ole32!_imp__RegOpenUserClassesRoot (76061654)]
269 760f9014 e8fe430100      call    ole32!WPP_SF_d (7610d417)
283 76087922 ff15fc160676    call    dword ptr [ole32!_imp__RegOpenKeyExW (760616fc)]
286 760f905b e8b7430100      call    ole32!WPP_SF_d (7610d417)
290 76087935 ff15e4130676    call    dword ptr [ole32!_imp__CloseHandle (760613e4)]
294 760f9065 ff150c140676    call    dword ptr [ole32!_imp__GetLastError (7606140c)]
295 760f90a1 e871430100      call    ole32!WPP_SF_d (7610d417)
298 7608793e e811010000      call    ole32!RegHelpResumeImpersonate (76087a54)
304 76087966 ff15fc160676    call    dword ptr [ole32!_imp__RegOpenKeyExW (760616fc)]
307 760f90e3 e8dfd70100      call    ole32!WPP_SF_Sdd (761168c7)
309 76087979 ff15f4160676    call    dword ptr [ole32!_imp__RegCloseKey (760616f4)]

That ole32!IsUserHiveOK looks interesting, so let's chase that down and see what we find, again just focusing in on the call statements:

0:010> uf ole32!IsUserHiveOK
200 760879cc e83c000000      call    ole32!IsElevatedToken (76087a0d)
205 760879e5 e83ae2ffff      call    ole32!GetTokenElevationType (76085c24)
221 760941e8 e81a000000      call    ole32!IsUIAccessToken (76094207)

This is, indeed, interesting. We're checking IsElevatedToken, and then we're calling GetTokenElevationType. What can TokenElevationType tell us? Let's check MSDN:

TOKEN_ELEVATION_TYPE Enumeration

The TOKEN_ELEVATION_TYPE enumeration indicates the type of token linked to the token being queried by the GetTokenInformation function or set by the SetTokenInformation function.
Syntax
typedef enum  {
  TokenElevationTypeDefault   = 1,
  TokenElevationTypeFull,
  TokenElevationTypeLimited 
} TOKEN_ELEVATION_TYPE , 
 *PTOKEN_ELEVATION_TYPE;
Constants

TokenElevationTypeDefault

The token does not have a linked token.

TokenElevationTypeFull

The token is linked to an elevated token.

TokenElevationTypeLimited

The token is linked to a limited token.

We can see how, using both elevation state and TokenElevationType, we can determine both the elevation state and if UAC is enabled or disabled. So, we've unraveled what's happening for COM.

But, almost immediately after posting, people began posting about exceptions to the rule, which we began investigating. The lesson here: OLE != OLE Automation. They are different things. And it turns out that OLE Automation doesn't have the fix we incorporated into COM itself. They're different code, incorporated into different DLLs, maintained by different teams. What does OLE Automation do? Let's take the same approach, disassembling the function and zeroing in on the calls it makes:

0:010> uf oleaut32!OpenClassesRootKeyExW
150 75a49f80 e8c7feffff      call    OLEAUT32!SuspendImpersonate (75a49e4c)
151 75a49f8b ff151412a475    call    dword ptr [OLEAUT32!_imp__GetCurrentProcess (75a41214)]
151 75a49f92 ff157413a475    call    dword ptr [OLEAUT32!_imp__OpenProcessToken (75a41374)]
155 75a49fad e8cafeffff      call    OLEAUT32!IsProcessElevated (75a49e7c)
159 75a5ab15 ff153413a475    call    dword ptr [OLEAUT32!_imp__RegOpenUserClassesRoot (75a41334)]
173 75a49fd4 ffd3            call    ebx
178 75a49fdc ff151012a475    call    dword ptr [OLEAUT32!_imp__CloseHandle (75a41210)]
182 75a78782 ff15ec11a475    call    dword ptr [OLEAUT32!_imp__GetLastError (75a411ec)]
185 75a49fe8 e842000000      call    OLEAUT32!ResumeImpersonate (75a4a02f)
191 75a4a05e ffd3            call    ebx
192 75a4a066 ff158013a475    call    dword ptr [OLEAUT32!_imp__RegCloseKey (75a41380)]

Things look a bit different here - all we call is IsProcessElevated. If you're running as admin with UAC disabled, this returns true - and the function never calls in to determine the token elevation type. OLE Automation did not get the same update that COM did!

Now, from the Windows side of things, we already have a bug open to fix this, but since I spread the word that it's working and some of you have contacted me suggesting that it isn't, I wanted to make sure it was clear: COM was, indeed, fixed to work with per-user registrations and UAC disabled, but OLE Automation was not.

What can you do in the interim? These are the workarounds I have heard about so far:

Use MIDL generated proxy/stub marshalling for interfaces instead of type libraries
Load the type library from the COM dll directly instead of reading it from the per-user registry hive

Incidentally, for those of you who were perplexed that Live Mesh was released but didn't support running as admin with UAC disabled until Windows Vista SP1 ... what do you think the odds are that there are some per-user COM registrations in there? Hmm...

Per-User COM Registrations and Elevated Processes with UAC on Windows Vista SP1

Chris Jackson — Fri, 06 Jun 2008 21:27:00 GMT

A while back, I was talking about per-user COM registration and elevated processes on Windows Vista.

True at the time was this fact:

It also means you won't pick up a per-user COM object if you are running as a member of the local Administrators group and you have disabled UAC for some reason.

And somebody dug this up and pointed out that this no loner appears to be true:

Doesn't seem to follow this after updating to SP1.
On my Vista Business SP1, running as an admin with UAC disabled, my program picks up COM registered to HKCU.
This was working fine - as described before installing SP1.
Is this intentional?

Yes, it is intentional - we changed the behavior. Having it behave this way was actively preventing people from using per-user COM, because there was a scenario (UAC disabled) where it would never ever work.

So, the behavior beginning with Windows Vista SP1 for per user COM registration is:

UAC Disabled - You see per-user COM classes

UAC Enabled - Not Elevated - You see per-user COM classes

UAC Enabled - Elevated - You do not see per-user COM classes

We believe that per-user COM registration has value, but developers are certainly not going to use this approach if it will never work on some percentage of desktops, no matter how small that percentage is (currently hovering at around 12% - but on the scale of Windows that's pretty huge). So we made that change. However, on machines with UAC enabled, we will help keep you more secure by continuing to prevent a standard user from injecting something into an elevated process using this mechanism.

Updated 16-June-2008: Aaron pointed out that I was overpromising to "keep you secure" and requested that I soften the statement a bit. Fixed it to be a touch less loosey-goosey.

UAC: The Greatest Thing Since the Gag Reflex

Chris Jackson — Thu, 29 May 2008 21:35:47 GMT

It seems that everywhere I turn, the computer press keeps implying that the only people who leave UAC turned on are people who don't really understand computers. In June 2008, for example, it's #6 on their list of tips (page 64 in the print edition):

6. Turn off annoying prompts. Vista added the "A Program Needs Your Permission to Continue" prompt to help prevent you from inadvertently installing malware or making unauthorized changes to your computer. It's annoying to see that dialog box constantly pop up. If you're computer savvy, you can turn it off by deactivating User Account Control in the User Accounts Control Panel.

Et tu, PCMag?

Clearly, we understand that there are a lot of people who are going to turn off UAC. But coercing people to turn off a feature that helps them by implying that not doing so means they aren't computer savvy... yowzers. I consider myself computer savvy, but I would never turn it off. I just do not trust the public Internet or everything I download from it to be an Administrator on my computer. UAC gives me a means to express my inherent mistrust.

Because it turns out it actually does help prevent you from inadvertently installing malware.

And of course I know you can just be more careful. But, if you think about it, being secure means going through a decision every time you launch something. You can either do a mental prompt before you take any action (does clicking this thing put me at risk, since I'll be giving it admin rights?) or to some smaller subset of actions which explicitly gain admin rights. So, with UAC, I have prompts, but I think less, because I only have to think when the prompts tell me to.

And if I'm not thinking, just doing - well, am I really being computer savvy?

What can I say, I'm lazy. I think saying yes every now and again requires far fewer cognitive resources than being mindful of each and every thing that I do on my computer, despite the vast differences in trust I allocate to each action based on its source.

My colleague Gerrard Lindsay described the "annoyance" in a way that really caught my eye:

Some annoying things that are still worth it:

Alarm clocks
The rumble strips on the edges of highways
The gag reflex
Fire Alarms
Door Locks
Not running as an administrator on XP

Just some food for thought. You can be computer savvy and enable UAC. It won't make you more popular, better looking, or drive a nicer car, but it will help you think less.

UAC: the greatest thing since the gag reflex.

Man, good thing I don't have a job in marketing.

Springboard Live! Real Talk about Windows Vista Deployment

I'll be joining the panel of bloggers discussing real world challenges deploying Windows Vista. If you're going to be at TechEd 2008, join us Thursday, June 12 at 10:00 am!

Why Does It Take So Long to See the UAC Prompt Sometimes? (Diagnosing Slow UAC Prompts)

Chris Jackson — Mon, 31 Mar 2008 23:15:40 GMT

I wanted to elevate a response to one of the comments on an earlier post to the status of a full post, so it's hopefully a bit more discoverable.

The author writes:

"I would't mind dismissing Yet Another Popup, if it would have the decency to pop up already. UAC takes for-freaking-ever to ask my permission to do something I just told the computer to do. If it happened right away, it would be no biggie, but I frequently have to wait 20, 30, 40 seconds (sometimes way, way longer--about 30 minutes for a game download and install once) before the UAC prompt on the secure desktop. This is why I want to turn the damn thing off--because of its horrible performance! And it's all well and good to blame this on ill-behaved apps, but who owns UAC? That's right, Windows. I suspect for most users UAC is just another reason why Vista comes across as one of the clunkiest Windows releases ever."

And yes, Jason, you have a very fair point - that user experience sucks, and I hate user experiences that suck! Let's discuss.

First, we need to determine where exactly the problem occurs, because there are two possibilities. The first is that we're having trouble transitioning to the secure desktop. Given the current implementation, this is generally caused by limitations in the graphics card drivers to support this transition. If you end up staring at a black screen for a while, then this is likely the culprit. Unfortunately, there isn't much to do about this. One option is to get a new graphics card. (Easier said than done, right?) The other is to turn off switching to the secure desktop for elevation prompts, which has a couple of issues. First, it's somewhat less secure (a malicious application could disguise the dialog by painting something in front of it, and since the boundary of a window message is the desktop any potential loopholes could be exploited to auto-elevate - let's just say we did the secure desktop thing on purpose). Second, we disable this via group policy, but home SKUs don't have group policy editing included, which means you end up resorting to an obscure registry hack (also easier said than done, right?). So, I'm really kind of hoping you don't fall into this bucket.

The far more common bucket would be the case where everyone would be impacted with a given exe - and there is something the developers could do about this (and you can too, if you throw a shim at it). So let's discuss this one, and we will continue to try to push the software ecosystem in this direction to resolve it through policy rather than technology.

When we need to authorize a request for elevation, we look at the binary to see if it is signed. There is a difference in the UAC prompt if the application is signed - instead of being kind of orange and scary, it's greyish and more neutral. But the fact that it's signed means we have to verify the signature. And herein lies the problem.

Clearly signatures are a good thing, particularly for huge downloads from arbitrary sites. So we don't discourage signing - quite the opposite! But say you have a 10GB setup.exe that gets prompted for elevation due to GenericInstaller (which tries to ferret out setups by looking for heuristic evidence). That means we have to touch the entire 10GB file to verify that the binary has not been modified since it was signed - and that's a lot of disk I/O (and the reason you wait for the elevation prompt). If you are running such a huge file repeatedly, you can skip over the signature check by applying the NoSignatureCheck shim using Compatibility Administrator - this will eliminate your wait. But, if you're only running it once, it may be worth it to you to actually perform the check.

What could the developer do? They could manifest the self-extracting setup.exe to request asInvoker. The unpacker could then launch a small application that does the setup, which is signed but small enough that the validation doesn't take long. So, instead of waiting to validate the entire self-extracting package (when you may not even need all of it) you only wait to validate the actual setup, which clearly you'd want to manifest as requireAdministrator if you are doing a per-machine installation.

If you are noticing one particular source of exes that take a long time to pop up, my guess is they are elevating the outside package and doing a complete signature check over the entire setup package. Let us know if we need to evangelize to one particular group of folks. Is there any one source where you see this happening more frequently than other times? For this is an instance where we, as a platform, have made it possible to be either high performance or low performance. We rely on third party developers to take the high-performance path, but we don't always reach everyone to tell them how. However, we can't remove the low-performance path, so we have to continue to extend our outreach. Clearly, we still have work to do.

As for your 30-minute experience - we have no clue. We'd have to debug that one.