Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1517530 - Make pkexec behave like UAC in Windows
Summary: Make pkexec behave like UAC in Windows
Alias: None
Product: Fedora
Classification: Fedora
Component: polkit
Version: 27
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Miloslav Trmač
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2017-11-26 12:24 UTC by XU Guang-zhao
Modified: 2017-12-01 15:17 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-11-28 13:58:53 UTC

Attachments (Terms of Use)

Description XU Guang-zhao 2017-11-26 12:24:29 UTC
Description of problem:
Under a fresh-installed Windows when the administrator wants to do some privileged jobs, a window will pop up and the user only needs to click one button; however, on Linux the user must type a long series of password. The password is intended to block strangers from using my laptop, and it is already achieved by the lock screen; the `sudo` `pkexec` or UAC is to prevent possibly malicious code from gaining high privileges, and since under Wayland mouse events cannot be intercepted, one button click is sufficiently secure as a long password.

How reproducible:

Steps to Reproduce:
1. Run `pkexec id`

Actual results:
A dialog pops up asking for password, and the user will get tired of this.

Expected results:
A dialog pops up with only two buttons, and the user only needs to click the 'Yes' button to continue.

Additional info:
This is probably not a 'bug report', but a feature request. Thank you very much. I tried to make some patch about this, but the whole picture is a little bit complicated, the code structure may need to change :)

Comment 1 Miloslav Trmač 2017-11-28 13:58:53 UTC
Thanks for your report.

1) You already can add yourself to the wheel group, in which case you are not prompted for a password at all.

2) Unlike Windows UAC with UI Privilege Isolation, the Linux userspace has by no means sufficient protection against malicious userspace processes running under the same account; Wayland protects only the window server side but the processes are quite free to attack each other without going through Wayland.  Therefore, a "click yes" button does not prevent an attack at all. (A password prompt is not great either, in that if we assume a compromised userspace, the attacker can capture the password; but at least the authorized user must be present and enter the password at least once, a root escalation can’t happen with the target being completely absent.)

There might eventually be enough application isolation (with “portals” and what not), but that’† just not the case now.

3) It is up to the ”agent helper”, in the GNOME case a component of gnome-shell, to decide how to authenticate the user; it is not fundamentally required to authenticate the user (if a set-uid-root application can determine that the user has agreed in some other way); and it could, in principle, integrate with the lock screen.  I agree that “presence detection” and not prompting for the password immediately after unlocking the screen would be nice.

Comment 2 XU Guang-zhao 2017-12-01 15:17:42 UTC
(In reply to Miloslav Trmač from comment #1)
> 2) Unlike Windows UAC with UI Privilege Isolation, the Linux userspace has
> by no means sufficient protection against malicious userspace processes
> running under the same account

That's essential, and this is why Flatpak is important; though, processes inside Flatpak have no-new-priv flag set, so there is no worry for privilege escalation by them. Still, thank you very much for your explaination!

Note You need to log in before you can comment on or make changes to this bug.