Re: gnome-keyring AppArmor and

[Stef Walter <stefw gnome org>]

On 01/16/2013 09:20 PM, Michael Terry wrote:
> Hello, GNOME Keyring maintainers!  I am investigating a potential
> feature in Ubuntu of allowing apps confined by AppArmor to have limited
> access to the secret service [1].
> 
> Namely, to be able to store and get secrets, but only the apps' own
> secrets.  (For now; maybe in the future we can add more ACL-like
> functionality.)
> 
> I know that libgnome-keyring used to have ACL support (and still has the
> defunct API), but that it was removed as security theater, because there
> was no way to reliably identify a caller.
> 
> Since AppArmor can reliably identify a DBus caller, we (Ubuntu) are
> interested in adding support to gnome-keyring for AppArmor.  Let me just
> run through my current thinking, and please let me know if any of this
> is upstreamable either in a more generic form or perhaps as an #ifdef. 
> Or suggestions on making it more upstreamable.
> 
> The following is a first pass at how this would work:
> 
>  * If a dbus caller is unconfined (normal everyday desktop apps like
> firefox), we don't change a thing.  They still have unfettered access.
>  * Otherwise, confined apps should not be able to see or interact with
> items they didn't create themselves.
> 
> To do the above, I'm considering:
> 
>  * When confined, we ask AppArmor for the caller's context name, which
> is unique to that app/caller.
>  * When confined, create items with a special key
> 'x-apparmor-create-context' with the above context.
>  * When confined, always list, get, or set items with that context key
> (i.e. add that key as a match property to all incoming calls from
> confined apps).
>  * When confined, we also have to be avoid a caller guessing an item's
> DBus path (or seeing it from a changed/created signal) and using its
> calls directly, so on any such item call, also check the context.
>  * When confined, don't let the caller see, touch, or match on any
> properties that start with 'x-apparmor-'.
>  * When confined, only allow access to the default collection (i.e.
> don't allow listing, querying, or creating collections to avoid leaking
> collection names as far as possible).  This will involve filtering dbus
> calls and signals a bit.  I'm not sure how useful or realistic this is...
> 
> Note that none of this revives or uses the ACL API.  This is just
> 'silent' confinement so far.

There was some discussion about this before from the SMACK perspective.

In principle I agree with a plan like this.

Some key points I'd like to add, which meshes with what you outlined.
I'm not bringing these up as contradiction, merely as clarification.

 * There should be no prompts for this stuff when access fails. Like
   you said it is 'silent'. This was the second reason that the previous
   solution was security theater.

 * We should treat unconfined apps as their own security context. That
   is a confined app should be able to access only it's own secrets, and
   unconfined apps should not be able to access any secrets for confined
   apps.

 * All of this only affects the reading/writing of the actual secrets.
   The items containing the secrets, and their attributes (which have
   *no* security guarantees) are still visible by all apps, and can
   thus be managed by the password manager and so on.

 * When implementing this we should make it flexible enough so that
   (in the future) we can also use SELinux or SMACK to get these app
   "context names" or identifiers.

 * Internally we can store these in the appropriate places in the
   keyring format for ACLs. There's no need to add any hacks and use
   item attributes or such.

 * Unfortunately in the current implementation of the dbus implemantion

 * The client side libraries won't need any big changes (modulo bug
   fixes or tweaks).

 * In Secret Service API parlance, the items created in another
   security context will never be able to be unlocked, although
   the keyrings containing them will be.

One remaining thing to answer:

Does any of the above have security merit unless gnome-keyring-daemon is
running in a restricted mode where other applications cannot trivially
load modules into it, or look at its memory in other ways?

Cheers,

Stef