Application Confinement (Gnome-Keyring)

= 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:
[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