Using the Windows Installer

An explanation of how to use the Windows Installer is well beyond the scope of this book. If you need to understand the basics of how it is used, please refer to the Microsoft Platform SDK. The Platform SDK documentation also lists a number of security issues you should be concerned with, and because the SDK gets updated much more often than this book, I'd encourage you to read the section entitled Guidelines for Authoring Secure Installations. That said, let's take a look at some of the issues you'll encounter:

Like any other software installation, you need to be concerned with installing applications under an administrator-level account into directories that could be modified by lower-level users. Unlike many installers, the Windows Installer provides you with a LockPermissions table that allows you to set access controls on files, directories, and registry keys.
An installation package contains a number of properties. Properties can be classified as private, public, or restricted public. If a user should be allowed to change a property, it must be classified as public, but if a package is run with elevated privileges, some settings may need to be set to restricted public. Never use properties for passwords or other sensitive information. The installer might write the property table into a log or the registry.
When using the installer to install a service, try to avoid specifying a particular user account. You'll encounter problems with user-password pairs stored in the installation package and, as above, sensitive data could end up getting written into a log or the registry. In addition to these problems, the package will need to be updated every time the password changes. To make matters worse, installing a service under the same account on many machines makes them all dependent upon one another for their security.
Packages should be signed in order to verify that they have not been tampered with, and this should certainly be done with packages that install with elevated privileges. If an administrator needs to repackage the application, it can be resigned.
A package should be authored such that a failure to obtain needed resources does not cause the setup to fail in a way that would compromise security. For example, if an installation application running with elevated privileges was unable to locate resources, an Open dialog box used to find a resource could possibly be used to manipulate the file system inappropriately. Measures that will help prevent this problem include checking to be sure that a user has all required resources early in the install process and using source resiliency mechanisms in case a network install point is not available. For additional details on source resiliency, look in the Platform SDK documentation index.
A transform is used to customize the application for a given set of users. It's generally best to use a secured transform. Secured transforms can be stored locally in an area where ordinary users cannot change them, or they can be stored at the source of the installation package.
Custom actions allow you to create installation routines that invoke external executables. Although it would be unusual for an application to need more than can be done within the Windows Installer, it's nice to be able to extend the functionality. If an application runs with escalated privileges, custom actions run under the user context of the installing user unless the msidbCustomActionTypeNoImpersonate bit is set, and then only if the administrator has permitted the install.

Although creating a Windows Installer package might be a little extra work, Windows Installer makes it much easier to deploy your application in environments where the console user isn't an administrator. Windows Installer is also one of the few installation mechanisms that allow defining custom access controls.