Guidelines for Authoring Secure Installations

Adherence to the following guidelines when authoring a Windows Installer package helps maintain a secure environment during installation:

1. Make any property set by the user a public property.
   Private properties cannot be changed by the user interacting with the user interface.
2. Do not use properties for passwords or other information that must remain secure. The installer may write the value of a property authored into the Property table, or created at runtime, into a log or the system registry.
3. Avoid installing services that impersonate the privileges of a particular user because this may write security data into a log or the system registry. This creates potential for a security problem, password conflict, or the loss of configuration data when the system is restarted.
4. Use the LockPermissions table to secure files, registry keys, and created folders in a locked-down environment.
   Add a digital signatures to the installation to ensure the integrity of the files.
5. Author your Windows Installer package such that if the user is denied access to resources, the setup fails in a manner that maintains a secure environment. Check the user's access privileges and determine whether there is sufficient disk space before installation begins.
6. Commonly, the installer should only display a browse dialog box if the current user is an administrator or if the installation does not require elevated privileges.
7. Use Secured Transforms to store transforms in a secure file system locally on the user's computer. This prevents the user from having write access to the transform.
8. Use the Security Summary Property to indicate whether the package should be opened as read-only. This property should be set to read-only recommended for an installation database and to read-only enforced for a transform or patch.
9. The installer runs custom actions with user privileges by default in order to limit the access of custom actions to the system. The installer may run custom actions with elevated privileges if a managed application is being installed or if the system policy has been specified for elevated privileges. For details, see Custom Action Security.
10. Use the DisablePatch policy to provide security in environments where patching must be restricted.
11. Use the AppId table to register common security and configuration settings for DCOM objects.

Courtesy : Windows Installer White Paper.