[FEATURE REQUEST] Run command before updating.

[Goth667]

Please confirm these before moving forward.

• I have searched for my feature proposal and have not found a work-in-progress/duplicate/resolved/discarded issue.
• This proposal is a completely new feature. If you want to suggest an improvement or an enhancement, please use this template.

Describe the new feature

Hi,
I want do propose a feature in the installation options of a package. It would be nice if it was possible to run a command before the installation or update.
A simple text field where you can add the command you want executed and a checkbox if it should run as Administrator.
Thanks

Describe how this new feature could help users

Some packages can't automatically be installed if the program is already running, hanging up or its files are already in use by another application with a shared library. Depending on the system, it would be possible to add a command that shuts down the application or deletes the settings file etc.

[mrixner]

Duplicate of #2160 and #2193 (which I do plan to implement eventually)

[marticliment]

Duplicate of #2160 and #2193 (which I do plan to implement eventually)

Please do not implement this feature yet. This feature can very easily lead to a privilege escalation exploit, and I want to make sure this is not possible.

[Goth667]

mrixner
Sry, apparently I did a bad job a searching before posting.

Martí Climent (@marticliment)
Would adding a user for impersonation to run the command work?

[marticliment]

Would adding a user for impersonation to run the command work?

The issue here is that someone with local access could modify settings contents to have any program run a custom post-install script/command, and if UniGetUI is run as administrator (which would be easy to trick the user into), the post-install script has been ran as administrator.
The same thing goes for the feature request that asks to specify a custom path for package managers. It can lead to escalation rights exploits, unless very carefully designed (for example, only to run if UniGetUI is not running elevated, or if a certain registry key is set, key which can only be added by an administrator user, so a user with such feature enabled already knows what they are exposing themselves to)

[Goth667]

Thanks for the explanation.

So having to set up a user under whom the command will be executed would be harder to do then to double click a .reg file.
Should we also limit it so the impersonated user can't be the current user?
A warning pop up would also help, I guess.

In the end if you get the user to run a .reg or script there is no need to do it in UniGetUI.

In the end it boils down to the war against the universe. Where as devs try to make software safer and safer for dumb users and the universe trying to produce dumber and dumber users.

[mrixner]

This feature can very easily lead to a privilege escalation exploit, and I want to make sure this is not possible.

One method I could think of to prevent this is simply asking the user for confirmation about every command; every time it tries to run a post-install command, UniGetUI will check if that specific command has been approved before, and if not throw up an approval dialog. This way, an externally modified command will need approval first. And to prevent the external command from just being set as approved, maybe there could be a "hook password" in the settings used to encrypt the list of approved commands? Thus approving a command would require the hook password and prevent an external program from running something arbitrary.

[marticliment]

UniGetUI will check if that specific command has been approved before, and if not throw up an approval dialog.
there could be a "hook password" in the settings

Yet again, any information that is stored on the PC could have already been compromised, since it is not stored under safe zones. I reckon that, however, if post-install commands are only run when UniGetUI is NOT run as administrator, there would be no possible exploit, since UniGetUI would execute your script in local user rights, but you already needed local user rights to force UniGetUI into performing such actions

[mrixner]

Yet again, any information that is stored on the PC could have already been compromised, since it is not stored under safe zones.

Even a one-way encrypted (I forgot the word for this, but this was what I meant instead of encryption) password? I imagine the password wouldn't just be stored in plaintext.

[Goth667]

UniGetUI will check if that specific command has been approved before, and if not throw up an approval dialog.
there could be a "hook password" in the settings

Yet again, any information that is stored on the PC could have already been compromised, since it is not stored under safe zones. I reckon that, however, if post-install commands are only run when UniGetUI is NOT run as administrator, there would be no possible exploit, since UniGetUI would execute your script in local user rights, but you already needed local user rights to force UniGetUI into performing such actions

As for the command before, would it be possible to kill the process of the application that will be installed with the package?

[marticliment]

Even an one-way encrypted (I forgot the word for this, but this was what I meant instead of encryption) password? I imagine the password wouldn't just be stored in plaintext.

You mean hashing? How would it decrypt the contents of the file?

As for the command before, would it be possible to kill the process of the application that will be installed with the package?

What do you mean?

[mrixner]

You mean hashing? How would it decrypt the contents of the file?

Yeah, hashing! It wouldn't need to decrypt anything; just hash whatever command is about to be run and if its hash is listed as an approved command then the command could be run, otherwise prompt the user about the command. This is how account passwords are implemented, is it not?

[marticliment]

This is how account passwords are implemented, is it not?

More or less yes, but still wouldn't solve the issue, since a malicious agent could still calculate the hash of their command and inject it into the database where it is stored

[mrixner]

More or less yes, but still wouldn't solve the issue, since a malicious agent could still calculate the hash of their command and inject it into the database where it is stored

That's where the password come in. You can hash the hook password normally and compare against the saved hash to see if it's correct; the hook password is only known by the user, so it doesn't need a special hashing algorithm. Then use a hashing algorithm that takes an input (a password / secret key) to hash the command, so the attacker cannot get the hash of the command without the user's hook password.