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: 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.

Series links:
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.
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:
  • The system is Windows 2000 or later
  • The user is not a system administrator
  • The application or product is being installed with elevated privileges

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:
  • If an object is not listed in the LockPermissions table, and replaces an existing object, the replacement gets the security settings of the object that it replaces.
  • If an object is not listed in the LockPermissions table, and does not replace an existing object, it receives no explicit security descriptor. The access to the new object is based on the attributes of its parent or container object.
It is recommended that the system administrator’s local group be included in all access control list. This ensures that the system administrator can access and maintain objects.

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
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:
  • Secure any additional files written by your custom action
  • Check buffer lengths and validity of all data read by your custom action. This includes properties that may supply data to your custom action, particularly those that use public properties provided by a user
  • Do not rely on external DLLs that are not trusted by the system on all platforms on which your installation package is intended to run
  • Carefully consider whether to use custom actions that use elevated privileges or impersonation. If your custom action must run with elevated privileges, be sure that the custom action code guards against buffer overruns and inadvertent loading of unsafe code. Note that during the execution phase of the installation, the installer passes information to a process with elevated privileges and runs the script. Any custom actions that run during the execution phase may run with elevated privileges
  • Gather all information provided by the user during the UI sequence. Do not prompt the user for any information that can’t be set using a public property. If your script custom action expands properties, take precautions that the custom action is secured against the possibility of script injection. Scripts may be logged in clear text

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:
  • Test your package for compatibility with the Windows Installer machine System Policy
  • Make sure you package runs with all user interface levels, none, basic, limited, and full
  • Test your package on NTFS partitions, both with elevated and non-elevated privileges
  • Test your package with different user roles. That is, make sure it installs and works correctly for normal users as well as highly privileged users
Ideally, you should test your packages on a test platform that exactly matches your live environment in terms of permissions, policies and suer rights.

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.