[Setup]: RedirectionGuard

Valid values:	`yes` or `no`
Default value:	`yes`

Description:

Controls whether Setup attempts to enable Windows' RedirectionGuard mitigation on its own process. Uninstall also enables RedirectionGuard for its process if it was successfully enabled during the most recent installation of the application.

The RedirectionGuard mitigation [external link] , available on Windows 11 and Windows 10 22H2, blocks traversal of NTFS junctions and symbolic links created by unprivileged users (or any non-elevated processes).

RedirectionGuard is particularly of benefit to installers that read or write files in locations that are writable by unprivileged users, such as {commonappdata}. For example, if an installer is known to access {commonappdata}\YourApp, an unprivileged user could create a junction at that location to redirect all traversals of {commonappdata}\YourApp to some other arbitrarily-chosen path. If the installer doesn't enable RedirectionGuard, then the junction could trick the installer into creating or modifying files in a directory that the unprivileged user cannot access themselves. This constitutes privilege escalation, and could potentially allow the unprivileged user to gain full control over the system.

Best practice, however, is to avoid accessing publicly-writable locations like {commonappdata} whenever possible. Configuration files and data files that are only meant to be written by the installer or administrators should be placed under {app} (i.e., Program Files), not {commonappdata}.

Note that this setting only affects Setup/Uninstall's own process. It is not inherited by any child processes, nor does it enable RedirectionGuard for the application that is installed. Applications that access files in publicly-writable locations should consider enabling RedirectionGuard on their own process, or checking for the reparse point attribute (FILE_ATTRIBUTE_REPARSE_POINT) on each directory and file that is accessed.

When RedirectionGuard blocks access to a path, any error message shown or logged will typically include the error code 448. If it turns out that a blocked junction was actually created for some non-malicious purpose, then the recommended course of action is to delete and recreate the junction with administrative privileges (by running MKLINK from an elevated Command Prompt). Disabling RedirectionGuard shouldn't be necessary.

Setup and Uninstall both support /NOREDIRECTIONGUARD and /REDIRECTIONGUARD parameters to override this setting from the command line.

RedirectionGuard status is logged, so you can verify whether the mitigation was active during installation/uninstallation.