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
|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.
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.
In the case of a managed installation, the package author may need to limit which public properties are passed to the server side and can be changed by a user that is not a system administrator. Some restrictions are commonly necessary to maintain a secure environment when the installation requires the installer to use elevated privileges. If all of the following conditions are met, a user that is not a system administrator can only override an approved list of restricted public properties:
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.
Every file, registry key, or directory that is listed in the LockPermissions Table receives an explicit security descriptor, whether it replaces an existing object or not. The Windows Installer attempts to preserve the security on objects that already exist on the system, but has these defaults, which may not provide a secure installation:
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.
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.
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.
Rule 67: Make Custom Actions Secure
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. To ensure better security, follow these guidelines:
Rule 68: Test Your Packages For Locked-down Environments
In corporate deployment scenarios, restricted functionality, rights and permissions are the norm. You should make sure that your packages deploy properly in such situations. These basic guidelines will help ensure that your packages work in a locked-down environment:
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.