PolicyKit/sudo authentication status desktop icon indicator
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
- Milestone target:
- None
- Started by
- Completed by
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)?
