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.

[ilyagr]

For a specific use-case, when Kate saves to a root-writeable file, it uses PolKit to authorize. Typing a password each time is annoying (when you are editing such a file intentionally), but saving without any notification that you're editing a file you might not want to be modifying feels dangerous.

Another alternative would be to add an option to Kate to ask for confirmation. I am not sure whether Kate's use-case is special or what the convention among Polkit-using programs is.

[blurrred]

Definitely a step in the right direction. We need to get over this hurdle.
It does not make practical sense to have users enter their passwords repeatedly after they've logged in. Windows doesn't do it. macOS doesn't do it. We shouldn't do it just for the sake of "being different." We shouldn't avoid better decisions made by other operating systems just because "they're not Linux."
Let's take out heads out of our bums, look up, and ask ourselves, "is it really necessary for users to have to enter their passwords dozens of times after logging in for basic things like updating?" What about when the update fails and, you guessed it, PASSWORD TIME!
It's security theater. It's... something else I'm not allowed to say on github.
It needs to end. The first thing I do with every new Linux installation on my PCs is remove polkit password prompts.
I have literally never suffered any detrimental results because of it. It's pure benefit.

[jrybar-rh]

Definitely a step in the right direction. We need to get over this hurdle. It does not make practical sense to have users enter their passwords repeatedly after they've logged in. Windows doesn't do it. macOS doesn't do it. We shouldn't do it just for the sake of "being different." We shouldn't avoid better decisions made by other operating systems just because "they're not Linux." Let's take out heads out of our bums, look up, and ask ourselves, "is it really necessary for users to have to enter their passwords dozens of times after logging in for basic things like updating?" What about when the update fails and, you guessed it, PASSWORD TIME! It's security theater. It's... something else I'm not allowed to say on github. It needs to end. The first thing I do with every new Linux installation on my PCs is remove polkit password prompts. I have literally never suffered any detrimental results because of it. It's pure benefit.

Easy there, please.
Though I definitely understand your frustration, let me please explain few things.
Polkit challenges the user against a specific action. These actions are defined by the software vendors, just like the level of authentication it should require. It's their privilege to define that. I absolutely incline to the fact that asking password for writing in a system file should be unrelated to asking password for removing a user profile. That's for that.
Removing 'polkit password prompts' (a more complex definition would help) sounds like the good old switching UAC off right after fresh installation of Windows, which reminds me personal anecdotes of people asking periodically for help with their computer "which behaves weird" (read "full of malware from the content they downloaded" after they turned UAC off).

I can see that along with 'allow[_any]' and 'auth[_admin]', there could be something like 'auth[_admin][_once]' with a permanent cookie for a certain action. Also adding just an 'Acknowledge' button instead of a password is an interesting proposal. All of these are good topics for discussion and consultation with other upstreams, but I cannot guarantee (nor promise) any implementation till this summer at least.

[jrybar-rh]

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.

The system is not just about a user that is logged in, but about the processes that run behind that. The fact that a user is logged in doesn't mean that any process should be allowed to do whatever it wants. And that's what polkit is for. I can see where the confusion comes from, because users only see that annoying window on faded background that asks for password again.
What polkit does is that it "provides an authorization API intended to be used by privileged programs offering service to unprivileged programs" (excerpt from manpage). It is not the user that is allowed to remove a user, add a printer, write in /etc, start a public server. It's a process (gnome-software-center, text editor, systemctl) that is running in unprivileged (i.e. yours or any user's) userspace that wants to modify the system, which, of course, definitely should be an authorized operation. And these are just processes that are visible to users. You want this security granular on practical level. What polkit does is that you can either automate it or provide a platform for challenging the user against a password. That's all.

[jedenastka]

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.

The system is not just about a user that is logged in, but about the processes that run behind that. [...]

You omitted the part of my comment where I said exactly that:

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.

[jrybar-rh]

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.

The system is not just about a user that is logged in, but about the processes that run behind that. [...]

You omitted the part of my comment where I said exactly that:

Quite the opposite, I had it on mind the whole time :) Sorry for not clarifying that up front. I wanted to uplift some specifics, especially granularity, the fact that the desktop user is not the only entity on the system and also the main purpose of polkit which is described on its manpage, so that no one here ever questions the purpose of security on the system. I started to get a feeling that it's happening.

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.