I met the guys from RunAs Radio back in Barcelona, and a couple weeks ago I had a chance to sit down and chat with them. Check it out.
One of the features that we pried away from Windows for Windows 7 is Windows Mail. You can, of course, install Windows Live Mail to get the evolution of the same product, another mail reader of your choosing, or just use web based mail – it’s not as if we’re ending mail as we know it.
However, we’re an app platform company, and removing anything has its impact. And yes, there were public APIs to drive Windows Mail.
This is a good way to illustrate exactly how hard you have to try to get an application to break on Windows 7. (Well, there’s always the sure-fire easy formula to get an app that breaks: reverse engineer Windows, write code around what you find, and then hope we never change it. But here I’m talking about apps that were technically following the rules.)
Let’s take one API: CoStartOutlookExpress. Seems straightforward enough, and it doesn’t work on Windows 7. But let’s really dig into it, because I’m guessing you probably don’t use this API too often in your code. If you follow the trail of execution far enough, you find yourself in msoert2.dll, in a little function that’s determining if you’re going to work or not. Let’s unassemble that function:
msoert2.dll Section .text (0x43D01000) CALL DWORD PTR [KERNEL32.DLL!GetModuleFileNameW] TEST EAX,EAX JZ 0x43D0A613 LEA EAX,[EBP-0x20C] PUSH EAX CALL DWORD PTR [SHLWAPI.DLL!PathFindFileNameW] TEST EAX,EAX JZ 0x43D0A60C PUSH 'WinMail.exe' PUSH EAX CALL DWORD PTR [MSVCRT.DLL!_wcsicmp]
You don’t have to be a master of assembly language, just read the functions. Here’s what we’re doing:
Yep – that’s right, if you wanted to use this API, you had to name your executable winmail.exe or it wouldn’t work. So, yeah – if you did that, then we’re going to break you.
And the fact that I’m here telling you about this is because people have done exactly that. Man, app compat sure is hard…
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"?> <!-- Copyright (c) Microsoft Corporation --> <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>
<dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="amd64" publicKeyToken="6595b64144ccf1df" language="*" /> </dependentAssembly> </dependency> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> <security> <requestedPrivileges> <requestedExecutionLevel level="asInvoker" uiAccess="true" /> </requestedPrivileges> </security> </trustInfo> <asmv3:application> <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSe ttings"> <dpiAware>true</dpiAware> <autoElevate>true</autoElevate> </asmv3:windowsSettings> </asmv3:application> </assembly>
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.)
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