Application Confinement (Gnome-Keyring)

Registered by Marc Deslauriers on 2012-10-11

Discuss how to improve gnome-keyring security for applications running within the same user context. For example, if application 'foo' is installed from extras, how can we prevent it from accessing:
 * the keyring at all (is DBus mediation via apparmor enough?)
 * only a specified key in the keyring

What other scenarios should be handled? Should this be integrated with AppArmor and if so, what would it look like?

Blueprint information

Status:
Not started
Approver:
Jamie Strandboge
Priority:
Medium
Drafter:
Marc Deslauriers
Direction:
Approved
Assignee:
Marc Deslauriers
Definition:
Approved
Series goal:
Accepted for raring
Implementation:
Deferred
Milestone target:
milestone icon ubuntu-13.04

Related branches

Sprints

Whiteboard

= Background =
gnome keyring can store passwords and when offline the storage is encrypted. when online it is decrypted
previous versions had ACLs to control access to the keyring. patched out because security consider when everything is running under the user session and several issues. (spoofing, tricking, X spoffing, opening keyring file itself,etc, etc).
Default assumption "when in the default user session with trusted components, we don't need the ACLs"
Going forward, this assumption changes because of the extras repository. Those applications will run under a sandbox. Some applications in default install of Ubuntu also run in a sandbox.
How can we protect the security of the contents of gnome keyring now that the assumptions about everything running under the user's session is not trusted
How to move forward:
- a daemon could be in place that runs as a different uid - if the application is already confined
- we could
No point if we applicatoin has:
- read and write to user's home - a confined application
- arbitrary access to dbus
Assumption: an unconfined applicatoin is trusted and can do anything. A confined application has limited access to HOME directory, and no access to DBus
Two options:
1. bring back ACLs and have gnome-keyring make decisions by having it ask apparmor to see who it is talking to. Then gnome-keyring can prompt that this application can access the keyring
2. Could have an agent that denies access to everything and then apps are forced to work through it being using different backends for gtk, gsessions, etc. gvfs, file chooser, dconf, keyring, show notifications, wm applicaton integration. New applications could be forced to use this.
 * have different backends that forces the confined application to only communicate via a socket
 * on the other end of the socket is another application (the agent) that is a helper. It is in a position to make access decisions
  * how does the agent make these decisions (opening a single file could be via file open dialog helper)
  * could virtualize paths for legacy applications
 * the program uses the platform in the normal way. So a program tries to get a password from libsecret like normal. The backend forces communication over the socket. The agent on the other end of the socket has the policy and can make decisions.
 * where does the policy live for this? is it in the agent, is it somewhere else?
Need to also support legacy apps and apps that may be statically compiled
Why does it have to be so complicated? gnome-keyring could ask for the security context of the application asking for the access, then the ACLs could be in place to make decisions based on that. The application is confined anyway and isn't allowed to talk to everything

From irc conversation:

<mdeslaur> mterry: I want gnome-keyring to ask apparmor if an app is confined when it attempts to read/write stuff
<mdeslaur> mterry: if the app isn't confined, it goes about doing it's business as usual
<mdeslaur> mterry: if the app _is_ confined and is trying to write something, I want gnome-keyring to store an ACL for the app
<mdeslaur> mterry: if the app is confined and is trying to read something, I want gnome-keyring to check the ACL for the app
<mterry> mdeslaur, and it can only read its own keys?
<mdeslaur> mterry: yes
<mterry> mdeslaur, is there any provision for confined apps to read other app or system keys?
<mdeslaur> mterry: no provision, no
<mdeslaur> so we're using the ACL field in the DB, but we're not really going to be using the API
<tyhicks> mdeslaur: So if an app from extras needs access to another app's key in gnome-keyring, the authors will need to get their app into the "real" archive?
<mdeslaur> tyhicks: in ver 1.0, yes...in ver 2.0 maybe we can resusitate the "Do you authorize this crappy app to access blah blah" dialogs that used to be in gnome-keyring

(?)

Work Items

Work items:
[mterry] Reenable gnome-keyring ACL code (medium) (2): POSTPONED
[tyhicks] Add apparmor integration to gnome-keyring ACL code (medium) (4): POSTPONED
[tyhicks] Add patch to Ubuntu package (medium) (0.5): POSTPONED