Prokoba's Blog

User Account Countrol. Advertised by Microsoft as the greatest security improvement since the switch to NT from Windows 9x.

But is it?

And great for whom? The users? The independent software vendors?

Let’s see.

A user is presented with two extra clicks when they need to copy a file to a protected folder with Windows’ own explorer. Not one, two! I guess this is usability – Microsoft-style!

A user wants to run a new program. He’s not quite sure how safe this new program from this new vendor is. It says it needs privileges. The user has to either give their consent or the program will not run at all. In my observations 99% of the users click continue 99% of the time. What protection does the UAC offer then to most users? Not much. But it sure as hell takes its countless click toll on your productivity.

But, hey, we all know that UAC was never meant to protect the poor old end users in the first place. It was in fact introduced to punish sloppy software vendors, which have created their programs to run with administrative privileges all the time. The Microsoft plan, apparently, is to persuade them to redesign their mess in a more secure manner, by splitting the sensitive parts that really need admin privileges from the rest of the software. A sufficiently annoying prompt, it seems, is the Microsoft way to achieve this.

But the product I’m working on is not a mess. It was developed and runs fine on pre-Vista platforms. It accesses files and registry keys carefully secured via ACLs. Only for me to one day wake up and find out that the respective components run with a ‘virtualized’ registry on Vista and changes to the registry are lost as soon as the process completes and are never seen by other users. You need full admin privileges to touch HKLM in the registry. What was all of my ACL pain for then?

The product I’m working on also keeps the password to a privileged account on the local system. It manages that password in a secure manner, very careful not to expose it as plain text in the process address space (e.g. in the .net parts of the system the password is always kept in a System.Security.SecureString). When it needs to perform a sensitive task it impersonates the privileged account, performs the task, then drops the privileges immediately. Simple. Flexible. Secure.

Doesn’t work on Vista!

The quick solution was of course to run parts of the system via the “runas” mechanism. Which immediately reduces security significantly, because now entire components run privileged, instead of a few lines within the component which actually need those privileges. But wait, it gets worse.

Due to the spectacular lack of proper software installation and updating mechanisms in all Windows platforms in existance, our product (like so many others) has its own. Our updates system will detect that a new version is available, will copy a few assemblies into a temporary folder and will execute the “updater” from there. This is needed because of another glaring Windows shortcoming – you can’t overwrite files which are currently in use (without a restart). What’s worse our update mechanism is MSI-based (yet another great Microsoft technology!) and MSI will ask you to close the “updater” and then try again. Whatever. Throughout the development of the product we’ve worked around all of this brain damage. But here’s the cool part: once the updater has run (after being elevated thru an UAC prompt of course) it wants to restart the calling application, whichever that was, as the standard (non-elevated) user that originally launched the initial app. How do you do that in Vista? You wouldn’t believe. But what if the privileged account was different than the original unprivileged user that started the application in the first place? You’re out of luck!

So all I want to say is,

“Thank you, Microsoft! That you for your wonderful products, and for the way you’re treating me as a developer!”