PolicyKit/sudo authentication status desktop icon indicator

Registered by Kees Cook on 2009-04-28

There needs to be an indication that PolicyKit is in an "unlocked" state, visible on the user's Desktop. Optimally, this same icon could be used to re-lock PolicyKit and sudo access.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
Marc Deslauriers
Direction:
Needs approval
Assignee:
None
Definition:
Discussion
Series goal:
None
Implementation:
Informational Informational
Milestone target:
None

Related branches

Sprints

Whiteboard

* Problems:
- sudo and gtksudo authentication caching is confusing
- Cached authentication for longer than necessary may facilitate malware/intruders
- No easy way in a graphical desktop to see we're in an "unlocked" state
- No easy way in a graphical desktop to cancel "unlocked" state

* Solutions:
- Get rid of gtksudo? (see separate blueprint)
- application developers may use UI additions to signal to the user that the application is using specific privileges (color, morphing dialog elements to avoid popups); potential DX contribution
- may also boil down to defining a set of guidelines for application developers and patches to enforce these guidelines for a group of critical applications
- the scope of the solutions to provide spans both sudo and pk-aware applications; sudo won't go immediately, we need to have a UI solution for it too
- whitelist/blacklist policykit actions? seems like a difficult list of maintain/validate
- there needs to be a migration strategy to move applications from using gksudo to PK
- decorate applications differently based on its permissions (running as root, with PolicyKit perms, etc)

* PolicyKit
 * no time-based token caching (one-time, per-session, or forever)

* Goals
 * need to avoid constant popping of auth dialogs (avoid Vista problems)
 * get rid of gksudo (separate blueprint)

Security aspects the user should be aware of:
 * "I have a valid sudo ticket"
 * "Am I root?"
 * TODO: identify other examples of more granular privileges
 * probably out of scope: privilege to use the cdwriter or /etc/security aspects

Security target (to help get the UI design right)
 * prevent malwares from stealing the user password
 * prevent malwares from becoming root
 * it's not about protecting user data or the user identity

 Note: exploiting specific privileges like "installing applications" may actually break the scope of the security target above.

* Future
 * MAC for per-window Xorg control
 * have keyboard LEDs lit when "correctly" prompting for the password

Idea (for further discussion)
 * should that also cover gpg/encryption applications; use similar UI hints to indicate to the user that he is performing a critical operation (unlocks its keyring)?

(?)

Work Items