Page MenuHome GnuPG

Kleopatra: Change running as Administrator from error to warning
Closed, ResolvedPublic

Description

In Gpg4win-3.1.15 we introduced a safeguard for users accidentally creating bad permissions in the GnuPG data folder by running Kleopatra as Administrator T5212.

This is important because the plugin system of qt might allow injection by other software running with user privileges to then also be executed in the context of the Administrator. And of course in the case that the user only temporarily runs with elevated privileges we get perimission problems on the homedir.

But now we get reports from users completely bypassing windows privilege separation and running everything as Administrator. In that case they can no longer use Kleopatra.
The error is a bit to hard, even though we want to discourage such users we don't want to loose them or have them on an old version so we should convert that to a clear warning.

Details

Version
3.1.15

Revisions and Commits

Event Timeline

https://wiki.gnupg.org/Gpg4win/RunAsUser has more explanation about this, and I had to give this to quite a number of people in support. (An improvement to the could be a link to a very good external or official explanation, does somebody know one? I've searched briefly but was not successfull to find strong recommendations by Microsoft.)

Just yesterday I had a user who only runs as root (I believe for historical and some development reasons).
So yes a 3.1.16 with this removed or a 4 beta would be appreciated. ;)

My suggestion would be to just keep using 3.1.14 But yeah there will be a 3.1.16 / 4 Beta soonish.

I don't think that you will find strong documentation as this would be like, "Please do not bypass all the privilege security that we have implemented in the past 20 years by running everything as root"
We are trying to protrect against privilege escalation attacks and the users are telling us: Uh, we don't care and also run our Web Browser as root

I've also suggested 3.1.14, but the changelog for 3.1.15 lists two potential important defects fixed for GPGOL (the empty recipient and the auto-retrieve).

About the documentation: I wonder why the recommendations are so weak/non-existent. There certainly is the need to explain this better. So probably somebody did. However it is not prominently published (for my search pattern).

(thanks for the comment)

Searching the web "Why UAC is important" finds a lot of explanations https://www.digitalcitizen.life/uac-why-you-should-never-turn-it-off/

Basically you should be searching on "Why privilege seperation is important" or something like that.

https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works has

The recommended and more secure method of running Windows 10 is to make your primary user account a standard user account. Running as a standard user helps to maximize security for a managed environment.

but also

The alternative to running as a standard user is to run as an administrator in Admin Approval Mode.

This leads for two questions for me:
a) What is about non-managed environments? (I think of single user installations)
b) Does the check for the current stop- and future warning-trigger when running

as administrator in Admin Approval Mode?
(The mode seems an alternative that at least Microsoft considers viable.)

On the UAC advantages, I've found an elder design guide at https://docs.microsoft.com/en-us/windows/win32/uxguide/winenv-uac

User Account Control experience helps prevent unwanted system-wide changes

UAC provides the following benefits:

  • It reduces the number of programs that run with elevated privileges, therefore helping to prevent users from accidentally changing their system settings, and helping to prevent "malware" from gaining system-wide access. When elevation is denied, malware is only able to affect the current user's data. Without elevation, malware can't make system-wide changes or affect other users.

However the "current user's data" are the most valuable data in a single user system as the following XKCD comic strip tries to illustrate (in an overdone way of course): https://www.explainxkcd.com/wiki/index.php/1200:_Authorization

I've found the following discussions somewhat interesting (in that they are not fully conclusive):

Otherwise interesting material:

Because elevations and ILs don’t define a security boundary, potential avenues of attack , regardless of ease or scope, are not security bugs. So if you aren’t guaranteed that your elevated processes aren’t susceptible to compromise by those running at a lower IL, why did Windows Vista go to the trouble of introducing elevations and ILs? To get us to a world where everyone runs as standard user by default and all software is written with that assumption.

It seems to be that "old" software may not be written with UAC and mechanisms around them, so they cannot easily be run on modern systems. (See Wikipedia UAC and Russinovich article). In addition the benefits of UAC are less valuable for single user systems.

Personally I have the feeling of not having understood the "integrity levels" and their implication on security, using UAC and a normal user account seems to have some security value. It is just unclear how large it is, but then again, we are talking about security where evaluations can change with the thread model and or other changes in the attack and migitation tree.

(So now I just have the difficulty to decide what to write on the wiki page. ;) )

I looked at the wiki and the content seems okay and what this issue requests has been done years ago. So resolved.