Windows 7 / MSI 5 "Dual-Purpose Packages" A No Starter? Print E-mail
General
Written by Darwin Sanoy   
Tuesday, May 19, 2009 12:25pm

I love dig deep into new functionality and find out how it works, but it also leads to unearthing implicit limitations - especially when you reconsider a technology in the framework of the current real environments it will need to work in, rather than the brave new world it seeks to define.

In preparing for a recent conference session I did some extensive testing of the big name feature in Windows Installer 5 which ships with Windows 7.  I have some concerns about this new functionality and I am sharing them in this post...

This new feature is called Dual-Purpose Packages (DPP) (formerly Per-User Applications). This feature allows the same Windows Installer package to be installed to the regular machine based locations or completely isolated to the user's profile. This entire process is controlled by a new property MSIINSTALLPERUSER - it is used in conjunction with a legacy property ALLUSERS. The really gory details of how this is configured and a video demonstration of it actually happening can be found in one of my previous posts here: MMS 2009 Follow Up Video Requirements ad authoring details for Dual-Purpose Packages under  MSI 5 are in a couple new SDK articles under the nomenclature "Single Package Authoring" Here are the guidelines: http://msdn.microsoft.com/en-us/library/dd408068(VS.85).aspx and example package is discussed here: http://msdn.microsoft.com/en-us/library/dd770204(VS.85).aspx

It's important to understand that software vendors have always been able to accomplish this type of install using an MSI package that is hard coded to install only to the user's profile, by creating custom functionality that could switch the package between machine and profile based locations or by relying on value-add features of their MSI package authoring tool.

To be sure there are some commercial software vendors that will welcome this feature - but my feeling is that it will be few, and here is why:

Per-User Installs Must Not Be Disabled

The property MSIINSTALLPERUSER=1 must be used in conjunction with ALLUSERS=2. This requires that MSI per-user installations must be enabled in your environment. I have been advising companies to disable MSI per-user installs for many years and so have others who work with enterprise packaging. This was because the MSI approach to per-user installs makes them very hard to manage.

Since in Windows 7 / MSI 5 a Dual-Purpose Package install can now be completely isolated to the user's profile - some companies may feel they are more acceptable because they no longer share files in "C:\Program Files" with all other per-user and per-machine instances of the same software. However, if MSI per-user installs are disabled in your environment, the per-user mode of a Dual-Purpose Package will not be available.

There are two Windows Installer policies that may cause MSI per-user installations to be disabled in your corporate environment. The first is "DisableMSI" or "Disable Windows Installer" (group policy name). If this policy is set to 1 in the registry or "For Non-manage Apps Only" in group policy, then then MSI per-user installs will not work (aside from group policy and SMS/SCCM deployment). This is a very common setting in corporations - one that I have been advising companies to turn on. ( SDK on DisableMSI ) The other is "DisableUserInstalls" or "Prohibit User Installs" (GP name). If this policy is set to 1 or "Hide User Installs", ALL MSI per-user installs are disabled. (SDK on DisableUserInstalls )

Whether or not your company has MSI per-user installs enabled affects your internal use of PUA, but it also affects adoption by any commercial software companies that service corporations - they generally don't want to depend on a feature that may be disabled at target clients because it will generate needless support calls.

One Package for XP through Windows 7

Another concern about Dual-Purpose Package adoption is the fact that commercial software vendors want to have a single software installation package that will service not just Windows 7 per-machine and per-user, but also service all the way back to Windows XP since it will be around for quite some time. Unfortunately MSI 5 DPPs rely on new special folders established as new for Windows 7. Specifically user profile isolated software installations have their own "Program Files" folder location. It is %LOCALAPPDATA%\Programs. %LOCALAPPDATA% existed on Windows Vista, but the new "Programs" subfolder and the APIs to locate it are not available until Windows 7.

ASIDE: I actually took a brief look into building a custom action to implement MSINSTALLPERUSER=1 back to Vista and XP. Since the registry softcoding for DPPs relys on legacy MSI features, all that appeared to be needed was to set the property "ProgramFilesFolder" to a reasonable value if ALLUSERS=2 and MSIINSTALLPERUSER=1. Unfortunately, on those previous releases the ALLUSERS property is manipulated by Windows Installer with incredible dexterity. So setting ALLUSERS=2 does not mean in it will reliably maintain that setting at the times that CostFinalize is evaluated in all run conditions. Before and perhaps after CostFinalize is the time when custom functionality would need to intervene to retrofit previous versions. Since it was: a) not proving to be simple, b) relied on MSI per-user installs being enabled, c) on Vista would require a separate package anyway, I abandoned my effort. A comprehensive custom solution within MSI could both work for XP through Windows 7 AND not rely on MSI per-user installs being enabled. If you know which products support this, have a product that supports this or take the time to build your own custom actions functionality you are willing to share, please use our contact us form to let me know so I can add the information to this post.

HKCU COM Registrations Ignored With Full Admin Token

MSI 5 DPPs installer per-user will need to have their COM registrations in HKEY_CURRENT_USER\Software\Classes (they then appear in HKEY_CLASSES_ROOT as well) so that administrator permissions / UAC are not needed for installation. However, if the software application (not the install) is run with a full administrator token, COM registrations in HKEY_CURRENT_USER are ignored. This is a security measure of Vista and later to prevent hijacked COM registrations from being transparently accessed by an administrator. Administrators have a full token whenever UAC is disabled or they elevate using UAC before running the software application.

This particular problem can be extremely difficult for software developers to debug. Actually it can be extremely difficult just to find the information on this - here's the official MSDN article: http://msdn.microsoft.com/en-us/library/bb756926.aspx and it is blogged by Chris Jackson here .   I haven't yet tested, but I have to think that the new HKCU shell registrations that were defined to support DPPs in Windows 7 would also be ignored.  They are referened in the Single Package Authoring article published to support MSI 5 - but the link does not lead to any information indicating which ones are HKCU capable.  I am guessing this will be another disincentive to DPPs use by commercial software companies because they really don't have control over whether end users will run their application with admin rights. (thanks to Gary Campbell of WebTrain for providing a heads-up on this UAC behavior)

Completely Silent Installation Of Unsigned Code

The gravest concern I have is that DPPs can lead to completely silent installation of unsigned code on Vista and Windows 7. Microsoft has really stepped up the bar on code signing since the release of Vista - basically the idea is "treat anything that is not signed with suspicion" - this is actually a very reasonable position to take. However, Vista also depends completely on UAC for code signing alerts. So if UAC is not required by a given process, then code signatures are not checked before execution. Since MSI 5 Per-User Applications effectively eliminate the need for UAC, they also avoid being checked for signing.

Although implementing code signature checking as a sub-function of UAC is a reasonable design decision, I have been lulled into a sense of security by the emphasis on code signing in Vista / Win7.

You can test this behavior yourself with our MSI 4 / 5 Test package. It can be downloaded from this article: Test Package and 30 Page Lab Manual for Testing MSI 4.0 (Vista) and MSI 5.0 (Win7) Features .

First you want to do a test to ensure you are testing what you think you are (an unsigned package) - once you have downloaded and extracted it, change to the folder "<extract folder>\DEtest\unsigned" and run the command line "msiexec /i detest.msi ALLSUSERS=1 /qb+" and at the UAC prompt verify that the package is unsigned. Click "No" or "Cancel" at the UAC prompt.

Next, test if the unsigned package can actually pass under the radar - rerun the package with this command line "msiexec /i detest.msi ALLSUSERS=2 MSIINSTALLPERUSER=1 /qb+" The package will install with no prompts.

Although the software can only be installed to the user profile - which limits its impact - it could be done completely silently.  A silent installation would require that the MSI be started with the /qn switch - something that cannot be done from the web unless the MSI is executed by an EXE or script - which would generally trigger UAC.  So this vulnerability would likely be trapped by existing OS features, but I was surprised to see it at all simply due to the code signing vigor that Vista and Win7 follow.

If anyone in your company's security department would be surprised by this functionality on Windows 7, this may actually be a sufficient reason to disable MSI per-user installs if you haven't done so already.  The main two policy settings that would accomplish this are covered in these Videos.

Conclusions

I always welcome useful new features in Windows Installer (like turning on logging within a package introduced in version 4!), but I have to guess that MSI 5.0 Dual-Purpose Packages will not enjoy broad adoption. An odd mix of legacy issues and the UAC COM limitation will most likely make it of limited use to developers who need to deploy to corporate environments.

Although this post has focused on Dual-Purpose Packages, there are several other welcome improvements in MSI 5 - things like enhanced ability to set permissions and improved services configuration. You can find a complete list here: http://msdn.microsoft.com/en-us/library/dd408114(VS.85).aspx

 

Add comment


Security code
Refresh