Remote Access tools (PUA)

[denelon]

Relevant area(s)

WinGet CLI

Description of the new feature / enhancement

The WinGet Community Repository has a policy for blocking PUA (Potentially Unsafe Applications).

I'd like to find a reasonable way to address the use of legitimate applications flagged as PUA rather than just an explicit block. This may require additional security reviews, administrative permissions for WinGet users to accept the risk or other mechanisms behaviors.

This work item is intended to track any applicable work necessary in the WinGet client to be able to allow these kinds of applications to be installed under certain circumstances.

Additional work would likely be required to adjust the policies for the community repository. If any other work items are created related to this, they should be linked to this issue.

Related to:

• New version: RustDesk.RustDesk version 1.4.6 winget-pkgs#345601

Proposed technical implementation details

No response

[denelon]

Inspired by: https://x.com/rustdesk/status/2036632270837297444

[mamoreau-devolutions]

Security vendors flagging legitimate apps as PUA, especially for a generic "remote access tool" category, is problematic for various reasons.

First, since these apps are legitimate, it's unfair to block them - after all, they're legitimate, even if they could be potentially unwanted. The PUA flag is also something that is inconsistently applied by security vendors, and there's usually no way to appeal on that decision or have it reversed.

Second, if you block PUA from package managers that would be considered like reputable sources of authority on where to install a specific package from, this invites users to install them separately. This creates an additional problem because users may just Google for the app to download and install it manually, which comes with the risk of finding a fake website serving a modified version of the app. If the app is to be installed, you certainly don't want to force users to use something different from WinGet if they were to pull it from WinGet.

RustDesk being flagged as PUA, preventing it from being updated in WinGet, and therefore requiring it to be pulled entirely in order to avoid serving old builds that weren't previously flagged as PUA is concerning. RustDesk is legitimate software. If you want RustDesk, why can't WinGet be used to install and update it.

One might say that it's just a few apps, just an edge case, so why bother? It concerns me deeply for Devolutions. We're sponsoring https://controlr.app/ an open source project which is in the same category as RustDesk. Should I be worried about WinGet distribution for ControlR? If anything that may be considered as "remote access tool" is at risk of becoming non-distributable through WinGet, then it means WinGet is not suitable to cover everything, and I need a non-WinGet solution. I want WinGet to cover everything, otherwise it loses value.

We already have an issue with the PUA flag at Devolutions. There is a security vendor which I will not name that has flagged https://devolutions.net/ as PUA because they consider Remote Desktop Manager as a "remote access tool". We don't even have a remote desktop server, RDM only has remote desktop clients in it, very similar to RDCMan. Several of our own customers have tried and failed to report this obviously unfair PUA flag to the vendor, unsuccessfully. This is why the current case with RustDesk has me spooked, even if the security vendor behind the flag is different. I simply don't trust security vendors not to wake up one day to start flagging legitimate software as PUA with real consequences, and no way to appeal.

TL;DR: PUA is potentially unwanted, legitimate software. Security vendors don't necessarily apply this flag in a consistent manner, and there's usually no way to appeal the decision if they consider you fall into the category, no matter how damaging the flag is for the company behind the legitimate software. For the users, it makes more sense to let them install PUA from the same package manager they would install all of their other software.

[santo998]

We need this. People who installed these packages may be running outdated versions

[stephengillie]

I'm reminded of the Policy-Test system, which uses simple text matching and seemingly-unknown lists to apply blocking labels. Such as Policy 2.9 on web browsers, Policy 1.8 on RAM HDD emulation software, and Policy 1.2 & Policy 2.7 seemingly random packages. Part of my role is to evaluate the validity of those label applications, and generate waivers where appropriate. But with ESRP, I do not have the same permission.

[denelon]

@mamoreau-devolutions
Thank you for taking the time to write such a detailed response. This will help when I'm working through a workable solution.

For others who are looking at this issue. If you have another perspective related to the business case for doing this, as opposed to just another example software, that will help. Please just add your 👍 on this issue to indicate your support and avoid "me too" comments.

[xlionjuan]

"Potential" Unsafe Applications has exists with legitimate reasons, the feeling for the devs when their softwares are being put in it is one thing, the real meaning for this is another thing

Users or sysadmins has their consideration when they decided to enable this warning, but most people, especially Microsoft knows that it is expected to have massive false positives

I don't think it is needed to argue what the - word "Potential" means, and it is absolutely not needed to create another "Sectigo drama" again.