coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

Howdy TJ,

(oop! reminder: use 'reply-all' to make sure that coapp-developers is in on the conversation)

What you're describing is a pretty far divergence for how Windows Installer works, and I don't think that we want to go there (even if it was easy-which it wouldn't be).

The trouble is, there is just far too many things that applications need to do, and by attempting to hamper them at install time, we will merely push them to do it at run time. We're not going to get into the business of monitoring what an application *does*, so forcing developers to work around us for a zero-gain isn't worth the time anyway.  The best we can hope for is identifying an offending application (and since it's signed, we've got someone to blame).

And actually, there is an advantage to making them do it at install time-Installations are tracked by the OS, and if something is damaging system performance or stability, it can get traced back to the offending installer (On Vista and beyond, look to the Reliability Monitor).


G
Garrett Serack | Open Source Software Developer | Microsoft Corporation
I don't make the software you use; I make the software you use better on Windows.

From: TJ [mailto:wizarrc@xxxxxxxxx]
Sent: Monday, August 30, 2010 12:54 PM
To: Garrett Serack
Subject: Re: [Coapp-developers] Package System Modifications

Mr. Serack,

I want to first thank you for letting me participate in the conversation.  I am a long time channel 9 listener and joined the mailing list when I first watched your video.  I've been programming c# for close to ten years now with moderate knowledge of native languages like c/c++.

>> How much registry access do application packages receive? Same as any MSI installer or do we restrict it in some way?
Well, I think we gotta allow unrestricted access for this. To do otherwise is just gonna make life hell for us. If this turns out to be a problem, we'll break stuff later.

If I can just comment on that for a minute.  The problem I see with giving unrestricted access to the registry is with ACL.  In order to give such access, I would imagine that the process installer would be running with elevated privileges.  When doing that, checks against existing, possibly important and critical windows registry entries could get corrupted, despite best efforts and code signing, etc.

My proposal would be a two-choice registry mode.  Fully non-trouble compliant applications opt-in to using a restricted registry mode where they play by the rules.  A second compatible default mode would virtualize the registry where any access attempts to read a value first checks the component specific entry (end user application or shared library, depending on the call stack where its being accessed from) then if not found, read the actual system value based on ACLs of the running process.  Any attempt to write to a restricted area will write in the virtualized area, thus avoiding any access denied errors.  I would imagine hooking into the process could do such virtualizations.  Where am I wrong on this thought and would this be too much overhead to provide some security safeguards?

Thomas Crowe