Policykit password dialogs are insecure as they do not keep focus
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
PolicyKit GNOME |
Expired
|
High
|
|||
policykit-1-gnome (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: policykit-1-gnome
Policykit password dialogs are insecure as they do not keep focus. There are advantages to the way gnome-screensaver and gksudo treat the password prompt. As it blocks out any other input or window, you are less likely to be inputting to another source.
I have experienced many time where I either discovered a password or shared my own because of this flaw in policykit.
Examples of the issue:
-Start an administrative utility which requests a password
-Get the password prompt up
-Either inset a usb disk or if you have touchpad sensitivity (tapp to click) **accidentally** click on a nautilus window in the background
-Type the password ans it shows up as a file search in the bottom right of the nautilus window
As you can see there are benefits to making sure the password is entered into the password prompt. policykit and many other password prompts do not lock out screen meaning the risk is higher that everyone will be able to see your passphrase in cleartext.
ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: policykit-1-gnome 0.96-2ubuntu2
ProcVersionSign
Uname: Linux 2.6.32-24-generic i686
NonfreeKernelMo
Architecture: i386
Date: Wed Sep 29 22:51:43 2010
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release i386 (20100816.1)
ProcEnviron:
LANG=en_US.utf8
SHELL=/bin/bash
SourcePackage: policykit-1-gnome
description: | updated |
Changed in policykit-1-gnome (Ubuntu): | |
status: | New → Confirmed |
Changed in policykit-1-gnome: | |
importance: | Unknown → High |
status: | Unknown → In Progress |
Changed in policykit-1-gnome: | |
status: | In Progress → Expired |
I just tested GNOME 3 Shell desktop environment and I have to say that they got it right. All authorization dialogs dim the screen and focus the keyboard for input. Would the security team be willing to preform a review of GNOME Shell's implementation of the fix for this issue and, if it fits the bill, recommend it to be implemented in gnome-based desktop environments (unity, gnome classic).