Re: gnome-keyring Question about ACL per storage item

[Stef Walter <stefw collabora co uk>]

On 2011-10-20 09:17, Elena Reshetova wrote:
> Hi,
> 
> I have been studying different solutions available in Linux for securely
> storing certificates, keys and other credentials and one of the
> solutions I am going through is Gnome Keyring.
> I saw that it used to have ACL per item in the storage, where one can
> specify basic read/write/delete rules and identify application (or
> applications?) that is allowed to use the item. However, this
> functionality is now marked deprecated and I could not find explanations
> for such decision.

The previous implementation was poorly implemented, poorly thought out,
and insecure. It caused a lot of trouble and all the distros were
patching it out long before we removed it. This was several years ago,
and I remember it being announced on the mailing list, but the archives
seem hosed :(

Some related explanations:

https://live.gnome.org/GnomeKeyring/SecurityPhilosophy

> The use case I am interested in is very simple. I am as a user would
> like to be able to control what of my secrets are accessible to which
> applications on the system. Because I may have very different
> applications installed on my system and not trust each of them in the
> same way. 

I've posted on gnome-keyring-list and seahorse-list about this before
several times...

The issue at its core is telling the applications apart. Not just the
ones that are running, but consistently across reboots, reinstalls and
upgrades. The linux Desktop (in general) doesn't run applications in
distinct contexts. So although two applications may look like different
applications to a user, but to the system they're just two processes.
They may be part of the same "application", or may not. There's nothing
really telling them apart.

Even path of the executable can't be used to tell applications apart.
Many (more and more) applications are not compiled down to a binary, and
so their executables are identical.

In addition using LD_LIBRARY_PATH or LD_PRELOAD, you can have a given
executable load whatever code you want. So if you had a trusted
application identified by its executable path, it would be trivial to
substitute and run other code instead of that application.

Lastly, gnome-keyring-daemon also runs as one of these processes on your
desktop, and prompts the user via X for unlocking of the keyring. Two
applications running under the same X session can access each others
windows, impersonate each other.

So to summarize, as it currently stands:

 * It's hard to tell applications apart on the linux desktop today.
 * gnome-keyring-daemon uses X, which essentially allows any
   application to get the user's master password.
 * We need to make such an ACL feature wouldn't just be security
   theater (see above link).

Another way to think of it is this:

  * All the applications running in a security context have access to
    *everything* any other application running in that security context
    has.
  * The security context most every application is running in is that
    of your unix user account.
  * Ergo, on the linux desktop today most every application can
    *everything* running in most any other application.

As Anders alluded to, it seems to me we need to solve that before we can
have solid ACL support. But I'd love to be proven wrong on this :)

> Are there any plans/desires to have such functionality supported in
> Gnome Keyring? It isn't listed in architecture goals and plans and
> that's why I am interested to ask.

All that said, it's certainly not something I'm against solving. However
the magnitude of this problem is greater than one which I can by myself
solve in my current available time I have to put into it :/

Cheers,

Stef