Patching software under UAP/LUA

Question

I'm not sure if this is the proper forum, so please let me know if there is a more appropriate place for me to ask these questions.

We have a patching system that is written to handle patching all of our games.  It handles binary differencing, and also knows about our very specific file formats, and can work with products installed years ago, before Installer 3.0 was released.  According to this document (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/least_privileged_user_account__lua__patching.asp), patching while in a Least Priviledge account requires installing using Installer 3.0 from removable media (among other requirements).  Niether of these are guarantees for us since a) our products don't use installer 3.0 tech, and b) we offer our games for download installation instead of just CD/DVD installation.  Hopefully I have established that the current sugggested route is not feasible for us.

All of that being said, I am trying to figure out how to make our patcher play nice with Vista.  I have had a few ideas, and am curious if these are possible:

1) According to this document http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/AccProtVista.asp, it is possible to prompt the user for admin credentials when I want to gain some privileges to update the Program Files directory.  This is good, but it might be a fairly frequent operation, since some of our games patch on a weekly basis.  Also, the patcher often restarts itself if it needs to patch itself, so if we update the patcher and a game on the same day, at least two admin password prompts are now going to be required. 
I would think that for both Mom's and Timmy's sanity, Mom would want a way to say, "Yes, I will let Timmy's game patcher update his games without asking me for a password."  In other words, it would be nice if I could offer a way for an admin to bless an app as always being able to run with elevated privileges.  I got the impression from the UAP chat a few weeks ago that this won't be possible, but that seemed surprising, and I am looking for someont to confirm or deny. 

2) Somewhat related to the above; I know that there is going to be an AppCompat database that determines what "legacy" apps can run as an admin without prompting.  Is there a way to add our app to this database if the admin says it's okay?  We can sign all of our apps to guarantee their origin, etc.

3) Is there a way for administrators to give write access to LUAs for particular directories?  If so, we could have an app that asked Mom for her password and then granted Timmy write access to our game folders in Program Files.  If that's possible, does this break the Games Explorer's ability for parents to monitor/limit their children's access to games?  I am concerned that this might open upt he game exe to hacking by little timmy, thus putting the game definition manifest at risk, but I'm not sure if that's the case.  Obviously, if signing of our executables means anything to the Games Explorer, we're safe, but I'm not sure about it. 

4) Lastly, does installing games on a per-user basis instead of a per-machine basis help with any of these issues?  Not being too knowledgeable about per-user installs, I wasn't sure A) where the files go by default, and B) if LUAs get more rights to access/edit their own per-user installed apps.  If they do get more access, this _might_ be an acceptable workaround, although it's obviously far from ideal.

Many thanks for any help you can provide...

    - Taylor

Answer 1

Bummer - 740 views and no replies.  I take it from this that the official MS folks aren't reading this particular forum?  Does anyone else know a better place to post such a question?

Many thanks,

    Taylor

Answer 2

Excellent questions.

 

Patching is one of the largest problems we still face for fixing our legacy codebase to run well as Standard User.  It is simply an admin operation to modify the Program Files directory… and probably always should be.  Enterprise Admins in locked-down environments need to be in control of the update process.

 

That being said, we absolutely need to provide a clean way to allow applications, and especially games, to update cleanly.

 

As you noted, MSI 3.1 states that MSP (the updater portion) will only work if the original MSI came from a CD.  The plan to change that is as follows:

• Windows Installer (MSI) 4.0 ships in Windows Vista
• Windows Installer 4.0 will honor the MSI 3.1 “update” statement
• Windows Installer 4.0 removes the restriction on the original install coming from a CD.  (Windows Installer 4.0 will honor the “update” statement even if the original MSI was not from CD)
• MSI3.1 MSP Update packages will run as admin on a Windows XP machine IF the user is logged on as an admin

 

That means that on Windows Vista, the MSP Update will allow the Standard User to update without elevation by the user even though it is an MSI3.1 package.  On XP, the MSP Update will be treated as a standard MSI package that will be elevated to complete the install… but since most home users are Admins, the update will just work (Yell if you think that is an invalid assumption).

 

In response to your questions:

 

1.       We don’t have a way to identify which applications should get a silent elevation and which applications should get an elevation consent prompt.  Therefore, everybody gets a consent prompt during elevation.  The threat is that while the setup application is running as admin, it will mark not only the update, but the game as well for silent elevation.  We NEED to get our ISV community to write better code… and we need the users to KNOW when they are consenting to run something on the machine that can affect the security of the machine.

 

2.       There is no App Compat database that determines what “legacy” apps can run as admin without prompting.  The App Compat database does have an Admin marking, but you always get an elevation prompt.  The theme here is:  all admin operations will get a prompt.

 

3.       “Loosening the ACLs” is a tried and true way for Enterprise Admins to get an application “working” as Standard User.  However, shipping this as a general solution has some serious security consequences.  Let’s use the older versions of Microsoft Office as an example.  WinWord-97 used to store the TEMPLATE.DOT files in Program Files.  If we loosen the ACLs on the TEMPLATE.DOT file, we allow any user on the machine to give any other user of the machine a macro virus.  Therefore, when we developed the Virtualization/Redirection layer for App Compat on Windows Vista, we made the redirection “per user” rather that “per machine”.  Each user has his own view of the world.  The PRO is that each user can only do harm to his own account.  In other words, in the WinWord example above, each user would have a personal copy of the TEMPLATE.DOT file.  The CON is that when two kids play the same game on a computer and log in with two different accounts, both kids think they have the high score on their favorite game that writes the high scores to Program Files since they each have their own copy of the high score file.

 

4.       Per-User installation of applications totally helps here.  EULAs probably have to be re-written since both kids probably will have a version of the game installed… and this introduces servicing problems too… but I personally believe that this will be the longer term direction of the industry.  ClickOnce is a viable per-user install technology, but unfortunately, the CLR (.NET) isn’t guaranteed to be installed on XP systems.  On Vista, there will be a CSIDL (common folder) that points into the users'  profiles.  The exact name isn’t set yet, but it will be something like USERS\Kidname\Application Data\Programs\YourAPP.  On XP, you will have to concat the %APPDATA% with \Programs\YourAPP to get the same path.  On Vista, there will be a CSIDL that is ACLd to All Users for storing High Scores etc too. 

 

I would love to work to completely understand your situation to make sure that your apps get updated.  Would you mind giving more information?  Did you make your own solution for updates or is it an off the shelf solution?

 

We have started a general discussion alias to handle UAP/LUA Questions.  Please visit: http://blogs.msdn.com/uap/.  Do you mind if we post your question and the response on the blog?

 

Thanks!

 

Steve

 

Answer 3

Hello Steve
Very interesting post.
I am quite in the same situation except mine is worst :-) :
Our activex (which I aim to make Vista and UX friendly) downloads and patch additionnal DLLs and not maps or user specific data.
On XP and previous operating systems the ActiveX is installed in %SystemDrive%\Program Files\company\product

Our current situation is RPC based broker using a requireAdministrator requestedExecutionLevel.
I am not satisfied with the user experience of this solution as the prompts may pop quite frequently since we patch frequently.

 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/Gaming_with_Least_Privileged_User_Accounts.asp ACL alteration would be the most suitable method, even if I noted it is not recommended.
I did not succedeed in altering just %SystemDrive%\Program Files\company\product

Do you have recommandations (except MSI or ACL modification effort ) to handle this case ?

thx

Answer 4

More and more software leads to unreliable desktops and. massive test matrix ..