Winget-AutoUpdate icon indicating copy to clipboard operation
Winget-AutoUpdate copied to clipboard

[Feature Request]: Digitally sign Powershell scripts

Open zxcvxzcv-johndoe opened this issue 1 year ago • 10 comments

The request

Hello,

We are using Applocker and it blocks running unknown powershell files from %programdata% (c:\programdata usually) where Winget-AutoUpdate seems to install it scripts.

So we get errors like EventId: 8007, EventTime: 2024-02-09T09:02:18Z, Source: Microsoft-Windows-AppLocker, Message: %OSDRIVE%\PROGRAMDATA\WINGET-AUTOUPDATE\FUNCTIONS\ADD-SCOPEMACHINE.PS1 was prevented from running.

Could you please digitally sign your scripts so we could whitelist them using a certificate?

Or is there way to install the software and its scripts automatically under C:\program files\ (where only admins can write by default)? Of course whitelisting them by certificate is preferred option but this could be a workaround.

Thanks,

Is your feature request related to a problem?

No response

Additional information

No response

zxcvxzcv-johndoe avatar Feb 09 '24 09:02 zxcvxzcv-johndoe

Sort of a deja-vu. I lost track how many times it was requested.

Copy-pastes from #514

I do not want to be devils advocate here but you can trust file by hash. Understanding the file hash rule condition in AppLocker I wouldn't expect a community-developed project to waste money on signing a single file for little or no profit.

If you have AppLocker in your company, it means that it is managed. The mouse doesn't bite. Going through the wizard to add a single file will take less time than writing in this thread.

Sort of a deja-vu. I lost track how many times it was requested.

Copy-pastes from #514

I do not want to be devils advocate here but you can trust file by hash. Understanding the file hash rule condition in AppLocker I wouldn't expect a community-developed project to waste money on signing a single file for little or no profit. If you have AppLocker in your company, it means that it is managed. The mouse doesn't bite. Going through the wizard to add a single file will take less time than writing in this thread.

And just maybe if this gets requested so often shows how much better solution signing the files would be compared allowing file hashes.

zxcvxzcv-johndoe avatar Feb 13 '24 07:02 zxcvxzcv-johndoe

And just maybe if this gets requested so often shows how much better solution signing the files would be compared allowing file hashes.

The product is covered by the MIT license, using it without an additional fee should be a sufficient nod to users asking for additional expenses related to the purchase of a certificate. The moment the author asked for money to collect funds for the purchase of such a certificate, the same mouths that "ask" will fall silent.

Is there any need, that C:\ProgramData\Winget-AutoUpdate is user writable? Having all scripts/EXEs in a directory, that is not writable by users, makes things much easier with AppLocker.

thenktor avatar Feb 16 '24 12:02 thenktor

Isn't the whole C:\ProgramData\ in RWX state for all users? If yes, then C:\ProgramData\Winget-AutoUpdate inherits ACLs from parent container. The only thing that comes to my mind is moving entire WAU INSTALLDIR to $env:ProgramFiles and leave logs where those are right now.

Isn't the whole C:\ProgramData\ in RWX state for all users?

That's correct, Windows standard. Furthermore WAU makes sure every script/folder with scripts is only RX for users

KnifMelti avatar Feb 16 '24 16:02 KnifMelti

No, in ProgramData normal users get write permission only through CREATOR OWNER permission to the files they have created, and they have another permission to create folders.

They do not have write access to all files there. You should be able to see the examples from screenshot below, probably easier to just test by yourselves.

image

zxcvxzcv-johndoe avatar Feb 19 '24 07:02 zxcvxzcv-johndoe

Users also have permissions to create files in ProgramData. So even if the Winget-AutoUpdate scripts are read only for users it is not save to create a simple AppLocker rule to generally allow execution from C:\ProgramData\Winget-AutoUpdate because a user can copy stuff to this directory and execute it afterwards. Therefore I've asked some posts before if write access to C:\ProgramData\Winget-AutoUpdate folder is needed at all for users.

thenktor avatar Feb 19 '24 13:02 thenktor

You can choose the path for WAU installation https://github.com/Romanitho/Winget-AutoUpdate?tab=readme-ov-file#advanced-installation -WAUinstallPath

Romanitho avatar Feb 19 '24 14:02 Romanitho

This issue is stale because it has been open for 30 days with no activity.

github-actions[bot] avatar Mar 21 '24 02:03 github-actions[bot]

This issue was closed because it has been inactive for 14 days since being marked as stale.

github-actions[bot] avatar Apr 04 '24 02:04 github-actions[bot]