Re: gnome-keyring AppArmor and

[Marc Deslauriers <marc deslauriers canonical com>]

On 13-01-18 10:29 AM, Michael Terry wrote:
> (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.

This was security theatre mostly because the X server doesn't prevent
confined apps from manipulating those prompts. In situations where
additional security is present, such as when confining X using the XACE,
or when using an alternative display server such as Wayland, it may be
possible to display such prompts in a secure fashion.

The question of whether or not the user is able to perform an informed
decision when one of these dialogs pops up is a separate issue.

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

I'm not sure how to prevent an unconfined app from accessing secrets.
How do you propose doing so?

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

I expect items and attributes would be hidden to confined apps also. At
the very least, it's an information leak to know what the user has in
his keyring.

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

Applications confined by AppArmor will be prevented from manipulating
gnome-keyring-daemon, so there is definitely value in enforcing this
security without necessarily doing anything to restrict
gnome-keyring-daemon itself.

Marc.