Friday 10 October 2008

Whose OS is it anyway?

I've got a question burning away in my mind - and I am not sure if I am right to ask it. I feel that, at the very core of Microsoft Vista and Windows Server 2008 rages a battle of hearts and minds over a possibly forgotten but all-encompassing issue.

The question that begs for a reply is; Whose operating system is it anyway?"

My focus is getting applications to work and the engineering effort required to deploy, install and manage thousands of applications on large heterogeneous networks. I have encountered an overcome numerous challenges including;
  • User Account Control UAC
  • Application Compatibility 
  • Security Restrictions

And now, I seem to face my greatest hurdle of them all; the mother of all technical challenges: Windows Resource Protection.

In Microsoft's own words; "Windows Resource Protection (WRP) prevents the replacement of essential system files, folders, and registry keys that are installed as part of Windows Server 2008 and Windows Vista."

Simply put; there is a system in place to ensure that you can not over-write either files or registry settings that the OS (Vista or Windows Server 2008) requires to function. In fact, most DLL's and executables within the Windows directory (the main OS directory) are protected under Windows Resource Protection (WRP) - meaning, that for most system files, you simply can not change or update these files or settings.

The principle of this system is pretty benign - keep the OS working. This increases stability, reduces support calls and generally makes most people are happy about this. The challenges begin when you need to update the OS for your own dark-hearted, nefarious purposes. Such as, to get an application to work….

Under Windows XP and Server 2003, there was a system called System File Protection (SFP) that relied on a cache (local copy) of "good DLL's". In the event that that a key OS system file was updated, the system would check the file version against this known list and replace the new file with the file taken from the local cache. This was a moderately successful security system with easy work-arounds.

HINT: stop the SFP service, update the local cache, update the target file in the system directory, restart the SFP service.

With Vista, there are a number of "approved" methods (Supported Resource Replacement Mechanisms) including;
  • Windows Service Packs installed by TrustedInstaller.
  • Hotfixes installed by TrustedInstaller.
  • Operating system upgrades installed by TrustedInstaller.
  • Windows Update installed by TrustedInstaller.
The Vista/Server 2008 WRP uses local security settings to restrict access to these protect files and settings - only allowing access to the TrustedInstaller module.

This makes things particularly difficult if you need to update a file on the OS - only Microsoft is allowed to touch these areas. My primary complaint is this; There should be a mechanism for system administrator to update the OS.

At present, I can not generate Windows Service Packs, customize Hotfixes or create my own Operating System upgrades. This is primarily due to restricted API's and Microsoft's freely acknowledged lack of documentation.

So this begs the question, "If I can't change it, who can?" And, if the answer is a certain software behemoth, I plan to raise a merry stink about this….

About Windows Resource Protection

Support Resource Replacement Mechanisms

1 comment:

Chris Jackson said...

If you're the administrator, you can take ownership of the file and change the ACL if you want. This is a reliability feature, designed to keep the OS in a known state, not a control tactic.