fix(installer): wrap shortcut Target in 'runas /trustlevel:0x20000'
Some checks failed
CI / build-and-test (push) Failing after 27s

The in-process ShouldDeElevate check (commit 191b2c5) didn't fire on the test box because ParticipantPID resolution against Win32_Process can return null fast enough that the check skips before the elevated explorer-spawned TeamsISO has fully booted. Belt-and-braces: ALSO wrap the shortcut Target so the runas demotion happens at shell-launch time, before TeamsISO.exe even runs. Result on the dev box: clicking the Start Menu / Desktop shortcut now lands a working medium-integrity TeamsISO with NDI discovery succeeding, regardless of explorer's elevation.

Uses [SystemFolder]runas.exe (resolved by MSI at install time) and Show='minimized' to hide the brief runas console flash.
This commit is contained in:
Zac Gaetano 2026-05-16 11:43:54 -04:00
parent 0e73746b58
commit 2552d46210

View file

@ -113,17 +113,39 @@
</ComponentGroup>
<!--
Start Menu shortcut to the WPF host. KeyPath sits on a per-user
registry value because the .lnk file lives in a per-user Start Menu
folder (ICE38/ICE43 enforce this even for perMachine installs).
Start Menu and Desktop shortcuts. The Target is intentionally
runas.exe (NOT TeamsISO.exe directly) with the /trustlevel:0x20000
argument. This drops the spawned TeamsISO to MEDIUM integrity even
when the shortcut is invoked from an elevated File Explorer.
Why: on admin-user boxes with UAC effectively disabled, double-
clicking the .lnk has explorer.exe as the spawner — and when the
spawned TeamsISO inherits explorer's elevated token, NDI Find
returns zero discovered sources (suspected window-station / desktop
handle inheritance quirk in NDI's mDNS layer; not reproducible from
any other parent). Wrapping with /trustlevel:0x20000 forces the
child to a restricted medium-integrity token regardless of the
invoking shell's level. Empirically verified to make discovery
succeed on the dev box where the bug first surfaced.
The /trustlevel:0x20000 magic number is the Windows "Basic User"
SAFER trust level — documented at
https://learn.microsoft.com/windows/security/identity-protection/windows-credential-theft-mitigation-guide-appendix#runas
Icon points at TeamsISO.exe (not runas) so the shortcut still shows
the app's icon, and WindowStyle=Minimized hides the brief runas
console flash.
-->
<ComponentGroup Id="Shortcuts" Directory="WildDragonStartMenuFolder">
<Component Id="StartMenuShortcut" Guid="*">
<Shortcut Id="StartMenuTeamsISO"
Name="TeamsISO"
Description="Per-Participant NDI ISO Controller for Microsoft Teams"
Target="[INSTALLFOLDER]TeamsISO.exe"
WorkingDirectory="INSTALLFOLDER" />
Target="[SystemFolder]runas.exe"
Arguments="/trustlevel:0x20000 &quot;[INSTALLFOLDER]TeamsISO.exe&quot;"
WorkingDirectory="INSTALLFOLDER"
Icon="TeamsISOIcon"
Show="minimized" />
<!-- Required by ICE64: Start Menu folder must be cleaned on uninstall. -->
<RemoveFolder Id="RemoveWildDragonStartMenuFolder"
Directory="WildDragonStartMenuFolder"
@ -137,20 +159,17 @@
</Component>
</ComponentGroup>
<!--
Desktop shortcut — belt-and-braces. Operators who lose the Start Menu
entry (or whose Start Menu doesn't materialize advertised shortcuts
cleanly) still get a Desktop icon. Same HKCU keypath rule as above.
-->
<StandardDirectory Id="DesktopFolder" />
<ComponentGroup Id="DesktopShortcut" Directory="DesktopFolder">
<Component Id="DesktopShortcutComponent" Guid="*">
<Shortcut Id="DesktopTeamsISO"
Name="TeamsISO"
Description="Per-Participant NDI ISO Controller for Microsoft Teams"
Target="[INSTALLFOLDER]TeamsISO.exe"
Target="[SystemFolder]runas.exe"
Arguments="/trustlevel:0x20000 &quot;[INSTALLFOLDER]TeamsISO.exe&quot;"
WorkingDirectory="INSTALLFOLDER"
Icon="TeamsISOIcon" />
Icon="TeamsISOIcon"
Show="minimized" />
<RegistryValue Root="HKCU"
Key="Software\Wild Dragon\TeamsISO"
Name="DesktopShortcut"