Valid values: | |
|---|---|
Default value: | yes |
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]](images/extlink.png)
, 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}.
Child processes started by Setup or Uninstall inherit the RedirectionGuard mitigation, except for child processes started by Setup with the (normally non-elevated) credentials of the user that started Setup initially, such as those started by [Run] section entries with the runasoriginaluser or postinstall flag, or by support functions ExecAsOriginalUser and ShellExecAsOriginalUser. Notes:
- If Setup didn't have to request administrative privileges, for example because PrivilegesRequired is set to lowest, or because Setup was started with administrative privileges already, the RedirectionGuard mitigation is still inherited.
- Most applications aren't affected by RedirectionGuard, but they might be, for example when the end user loads files from their OneDrive Personal Vault.
- This setting doesn't enable RedirectionGuard for the application that is installed, so only instances of it started by Setup or Uninstall are affected. 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.
See also:
Setup Command-Line Parameters
Uninstaller Command-Line Parameters