Re: gnome-keyring AppArmor and

[Michael Terry <michael terry canonical com>]

(I just noticed the subject line is odd.  The copy in my Sent folder 
says "AppArmor and gnome-keyring", but the copy that the mailing list 
sent out is garbled.  Weird.)

Thanks for the reply!  Further comments below.

On 01/18/2013 05:24 AM, Stef Walter wrote:
> 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.

Agreed.

>   * 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.

Agreed regarding confined apps.  But is it valuable or even possible to 
prevent unconfined apps from doing anything?

>   * 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.

Just so we are on the same page, I gather you are saying that items 
stored by confined apps should be visible to unconfined apps.  Not that 
confined apps can see attributes of items stored by unconfined apps.

Agreed as far as that goes (because, as I note above, I had assumed that 
unconfined apps would have no restrictions at all, as it is today).

>   * 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.

The different systems would probably not be able to share identifiers, 
but agreed that there shouldn't be any reason each system's identifiers 
could not be stored side by side.

>   * 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.

Ah interesting.  I'll look more into that.  Is there still support 
internally for reading and writing those ACLs?  The wiki page below is 
not super helpful.

https://live.gnome.org/GnomeKeyring/KeyringFormats/FileFormat

>   * Unfortunately in the current implementation of the dbus implemantion

This thought seems cut off.

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

Yeah, ideally the client side library wouldn't need any changes at all.

>   * 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.

OK.  Though I think keyrings should be a little locked down as well.  
Specifically, that confined apps can only use the default keyring.

Since keyrings don't currently have ACL support (though we could do it 
via special properties, but you weren't excited about that), that means 
that confined apps can share information or glean information about what 
other apps are installed by reading keyring properties or aliases.

Perhaps I'm being a bit paranoid, but I figured it would be safer just 
to leave confined apps only able to use the default keyring and not know 
about other keyrings.

> 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?

I believe the above has no security merit unless 'confined' means 
something useful.  Either gnome-keyring-daemon is protected, or the apps 
themselves are sandboxed in some way.  AppArmor does the latter.  But 
I'm not a security person, so my understandings of the various possible 
attacks is not very deep.

Maybe Marc or Tyler (cc'd) can clarify the limits of a confined app with 
regard to the running gnome-keyring-daemon.

-mt