Re: gnome-keyring Question about ACL per storage item

[Elena Reshetova <elena reshetova gmail com>]

Hi Stef, 

Thank you for the reply and explanations!
 I fully agree that making ACL for applications without a reliable way to identify an application
 (that maybe a collection of binaries, libraries and etc.) is pointless. However, I think current 
Linux already have mechanisms in place for doing this. Mainstream LSMs allow you to group 
applications to separate security contexts and therefore being able to distinguish between
 them in a secure and reliable way. We are using Smack as our AC module and group applications
in certain AC domains. In a run-time the smack label of a process defines the security context of this 
process. This is smth you can reply upon. Even if all applications are ruining with user session uid/gids, 
smack labels can be different and allow you to separate between applications. Also, update case is
handled: updated application will get to run in the same domain, and therefore can access to the 
same set of security credentials/keys and etc. 

Handing shared libraries and plug-ins is smth really interesting, but can be solved for example 
via additional checks on mmap (LD_PRELOAD and similar mechanism are still going through 
the same mmap hook). There are other alternatives to solve a problem of loading untrusted code
 to trusted applications, too.

Now about the X session. This maybe the only one actual current problem. However, if you run
gnome-keyring-daemon with a separate smack label, things may become easier. 
I know that Casey has recently looked inside X server and he might have better suggestions on 
solving this problem. 

All, in all, I think we can make implementation to be proper for some distributions that either use LSMs
or have other way to reliably identify an application on the platform. Android was doing this with unique 
uid/gids, so that can be other approach, too. 

Best Regards,
Elena.

On Mon, Oct 24, 2011 at 11:32 AM, Stef Walter <stefw collabora co uk> wrote:

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