UAC in MSI Notes: How I Root Cause The Problem

This is the second in a series of notes about UAC in MSI.  Per the earlier caveat, these are just my notes and not an official position from the Windows Installer team.  The previous entry was the introduction to the series.  This entry will talk about how I think about root cause for the problem being solved.

Progression to Separating Users from Machines

The Windows Installer itself has been around since 1995 which also happens to be the year of the most heralded version of Windows: Windows 95.  Up to that point, identity of the Machine and User had a strong 1-1 to correlation.  At the time, it was rare that a Machine had more than one User on it as well as rare that the User of the PC with anything but full Machine-wide rights to the system. 

An example of the early 1-1 correspondence was the fact that the My Documents folder was rooted at the base of the Windows Partition, thus “C:\My Documents”.

 

First Generation of Separating Users from Machines

What I consider the first push for a stronger definition of Users separate from the PC Machine came with the broad adoption of connected PCs inside corporations.  The first requirement was integration of the authentication and authorization systems provided by network infrastructure from which Active Directory was born.   The second requirement was the push to better manage the Machine as a company owned asset separate from the User on the Machine from which Group Policy was born.   The third requirement was separating the storage for multiple users on one machine from which CSIDLs were born.

Following the earlier example, corporations had built up a convention to put the user name under the My Documents, e.g. Jane Doe’s documents would be kept distinct from Joe Buck’s documents with subdirectories: “c:\My Documents\JaneDoe” and “c:\My Documents\JoeBuck”.  Through considering the corporate customer feedback, the Windows Shell responded to these conventions by creating OS supported conventions and APIs for separating user contexts.

 

Second Generation of Separating Users from Machines

What I consider the second push for a stronger definition of Users separate from the PC Machine came with the broad adoption of connected PCs outside of corporations.  I've heard it said that, in projecting the Internet Tidal Wave, the architects of Microsoft did not project its serious ramifications for security.  As the non-corporate world became broadly connected to the internet, the lack of defense in depth of the platform became a great issue for most non-corporate users .  The ramifications for the lack of trust in the Windows platforms in broad deployment became so great that the Trustworthy Computing initiative  was born.

As the nimble and brilliant minds looked broadly at the security landscape, they identified the single largest security problem with Windows was that most folks were running with full Machine-wide (administrator) rights.  From a security perspective, when you get owned running under a Machine-wide account, game is over and you have to flatten the machine to get back to a secure state.  With this perspective, those setting priorities for Windows Vista decided getting users to run without Machine-wide rights was a key pillar of the release and thus the User Account Control  feature was born.

User Account Control in Windows Vista is first and foremost a security feature.  In a nutshell, UAC intentionally flips the polarity of the default user experience on Windows from full Machine-wide permissions to simply Standard User permissions.  Starting with Vista, UAC will forever change the security experiences on the Windows platform (in my opinion).

With UACs emphasis on the User, it effectively further drives the separation User and Machine identities.  In that UAC puts non-user specific locations out of reach of a user without access to admin rights, there is now security driven substance to the notion of a User.

As you knit together these UAC in MSI notes, I believe you can see how the choices we've made are each small examples in the progression to separate users from machines.

Third Generation of Separating Users from Machines

What I consider the third push for a stronger definition of Users separate from the PC Machine is on the drawing board now.  While I've been told I shouldn't talk about it, the UAC team has started to reference their future thinking.  Before I can get to that distant future, I need to finish this near term future.

Comments

• Anonymous
  September 21, 2006
  Windows Vista introduces a security concept called User Account Control (UAC) which has multiple impacts
• Anonymous
  September 24, 2006
  PingBack from http://blog.devinstall.com/?p=6
• Anonymous
  September 30, 2006
  Robert Flaming has been posting a series of articles describing how Windows Installer interacts with...
• Anonymous
  October 09, 2006
  I am not sure what is meant by "Windows Installer itself has been around since 1995" - it has only been around since the release of Office 2000. I think the first generation of user and machine seperation was the unified "Registry" memory resident namespace having a user oriented section and a computer oriented section.  This approach propagated into NT from it's birth on OS/2. Having a single memory resident namespace that is only complete when a specific user context is completely loaded has actually (IMHO) been the source of much frustration and work in software installation since it always needs to be accounted for.  File based name spaces can be accessed from any user context since - such as UNIX home directories and computers directories for storing applications. .NET is actually reeling us back to the pre-registry days by allowing the storage the equivalent of COM registrations on disk (manifest files) alleviating the burden of the constant need to maintain a memory based, user specific name space.