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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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
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 usersIdeally, you should test your packages on a test platform that exactly matches your live environment in terms of permissions, policies and suer rights.
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.