Feature request: confirmation without authentication

[xi]

Currently it is possible to either silently allow actions or to ask users for authentication. I think there could be a third option in the middle where users are asked for confirmation, but without having to enter their password. Crucially, this would allow users to know that a request was made.

Specifically, I am asking for a set of confirm_* rules similar to the existing auth_* rules.

A very similar thing is available in WebAuthn, where confirmation (user presence) is always required, but entering a PIN (user verification) can be discouraged, recommended, or required.

[jrybar-rh]

Definitely disagree. Any malware that takes over mouse control can click on the "I agree with action take.over.the.whole.machine". The purpose of asking for password is to verify that it is really THE user.

[xi]

I am not proposing that this should be used instead of auth_*, but there might be cases where this could be used instead of allow where auth_* is too intrusive.

For example I am thinking of org.freedesktop.Secret.Service (e.g. gnome-keyring) that currently gives applications access to secrets without prompting the users (I am not sure if gnome-keyring uses polkit at all).

I believe that confirm_* rules fit well into the polkit architecture and would enable new use cases that may have not been considered before.

[jedenastka]

Any malware that takes over mouse control can click on the "I agree with action take.over.the.whole.machine".

If you have such malware running, you have bigger problems to consider. Said malware could wait for a legitimate prompt, keylog the password input, then invoke it's own prompt and enter the keylogged password.

Edit: After considering alternatives for #472, I now really started questioning if admin passwords have any use at all, and this request seems to not only provide a reasonable option, but also a reasonable default.

If you are logged in, you are already authorized, and considered to be the user by basically everything. You have access to all data, including files, browser cookies, maybe an unlocked password manager etc. (xkcd 1200: Authorization). You being able to alter the system is just another consequence of being you (the administrator). If you really want to have a "double check", it shall be configurable, but I have doubts if this could possibly ever help.

I do wonder what security experts have to say on this topic (a security researcher going by LiveOverflow did a video on why security "best practices" should be questioned... That video actually includes a section on sudo and security-sensitive actions, not directly related to this case, but sorta similar), but personally - I just can't find a reasonable explanation for admin passwords to exist.

The second level of authorization is important, but for a different reason - software running as the same user, but not with the same privileges (sandboxed) can try doing a security-sensitive action. Then, the user should be able to authorize that program to do this action. It also serves as a way to protect the user from their own mistakes, and causing damage to the system. In these cases, confirmation-only authorization seems entirely sufficient.

A case where a password is necessary is a user that is not an administrator trying to do a security-sensitive action. Here, the authorization by another user that is an administrator is necessary, and in the desktop use case desirable for shared computers.

Microsoft already does this with Windows's UAC, so there is some precedent. I also recall Canonical's Ubuntu having a similar behavior with sudo (NOPASSWD by default), but can't confirm that.

Anyways, it would be good to see this as an option first. This discussion might be better had later, but I wanted to share this.

[erin-desu]

Definitely disagree. Any malware that takes over mouse control can click on the "I agree with action take.over.the.whole.machine". The purpose of asking for password is to verify that it is really THE user.

We have Wayland nowadays and any sane compositor won't give any random app access to move mouse cursor just like that.

If you use X, everything you do in the graphical console is inherently vulnerable for any running program.