Tao of the Windows Installer, Part 6
Well, here we are with the last part in this series, where we'll be looking at security in relation to the Installer. As I'm sure you're aware, Microsoft take security very seriously, so don't let the fact that this is the last section make you think it's just tagged on at the end to meet some "security quota" for Microsoft documents. And don't be tempted to tag security on at the end of your packaging process either.
Before I finish up with the series, I'd like to thank everyone who has provided feedback on the blog or to me directly. In particular, thanks to the following individuals for contributing ideas and reviewing the posts:
- Robin Drake, Windows Installer trainer and consultant
- Robert Flaming, Windows Installer Program Manager
- Carolyn Napier, Windows Installer development lead
- Tyler Robinson, Windows Installer Program Manager
- Hemchander Sannidhanam, Windows Installer developer
- Heath Stewart, Developer
As mentioned at the start some months ago, this series should be available later in the year as a downloadable white paper. Keep an eye on the blog for details.
|Security Considerations Rule 57: Install Managed Applications into a Secure Installation Folder
A “secure installation folder” is one for which non-admin users do not have change or modify permissions. There is little point in securing the installation with Group Policy, Software Restriction Policies, Digital Signing, etc., if the user can simply change the application files after install. You should also secure all of the applications registry data in a similar way.Rule 58: Be careful When using Properties for Passwords or Other Sensitive Information
The installer may write the value of a property authored into the Property table, or created at run time, into a log or the system registry, which is obviously not good security for things such as passwords. Ideally, avoid using properties in this way, but if you must, then use the MsiHiddenProperties property to makes sure the information is not logged.Rule 59: Use Restricted Public Properties to Restrict the Public Properties a User Can Change.
Rule 60: Avoid Installing Services That Impersonate the Privileges of a Particular User
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.Rule 61: Use the LockPermissions Table to Secure Files, Registry Keys, etc.
Rule 62: Add a Digital Signatures to the Installation to Ensure the Integrity of the Files
The Windows Installer version 2.0 and later uses digital signatures to detect corrupted resources. A signer certificate may be compared to the signer certificate of an external resource to be installed by the package to ensure its integrity. Digital signatures can be used with packages, transforms, patches, merge modules, and external cabinet files.Rule 63: Fail Securely When the User is Denied Access to Resources
Author your 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. Commonly, the installer should only display a browse dialogue box if the current user is an administrator or if the installation does not require elevated privileges.Rule 64: Use Secured Transforms to Store Transforms Securely on the Local System
Secured transforms are stored locally on the user’s computer in a location where, on a secure file system, the user does not have write access. Such transforms are cached in this location during the installation or advertisement of the package. Only administrators and local system have write access to this location. A non-admin user would not be able to modify the transform file. During subsequent installation-on-demand or maintenance installations of the package, the installer uses the cached transforms for increased security. You can enable the use of Secured transforms on the command-line, using Group Policy or by setting the TRANSFORMSSECURE property. See the SDK for details.Rule 65: 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. Database editing tool should not modify a read-only enforced database and should issue a warning when an attempt is made to modify a read-only recommended database.Rule 66: Use the DisablePatch and AllowLockdownPatch Policies to Provide Security in Environments Where Patching Must be Restricted.
DisablePatch is a per-machine policy that prevents the installer from installing patches. This policy can be used in high security environments where patching must be restricted. AllowLockdownPatch is similar but still allows administrators to patch existing products that were installed using elevated privileges.Rule 67: Make Custom Actions Secure
Rule 68: Test Your Packages For Locked-down Environments
Rule 69: Use Software Restriction Policies to Restrict Package Execution
Software Restriction Policy (SRP) is a mechanism introduced in Windows XP that allows administrators to restrict the execution of applications based on various criteria such as the file hash, path, URL zone and publisher. The Installer is fully compliant with SRP and you can use it to restrict the execution of MSI packages, patches and transforms. If a package, patch, or transform is restricted, the Windows Installer displays an error message and logs an entry in the application event log. Software restriction policy is evaluated the first time an application is installed, when a new patch is applied, and when the installation package is re-cached.
[Author: Richard Macdonald]
This posting is provided "AS IS" with no warranties, and confers no rights.