Re: Seahorse and clear text passwords: a proposal for a pragmatic solution

[Stef Walter <stef-list memberwebs com>]

Thorsten Sick wrote:
>> The first and foremost 'real' thing we can do, to make all these
>> security dreams a reality, is help Linux get a concept of signed
>> applications (think iPhone, Mac OS) ... Or some other way to
>> differentiate between applications, or at least applications running in
>> different security contexts.
> 
> I am working for an anti-virus company. We get a large amount of
> _signed_ malware.

I agree. I wasn't talking about trusting applications based on their
signature. I was talking about differentiating...

The point here is that we have no solid way to differentiate between
code running on the user's Desktop as long as it's all running in the
same security context. Many of these ideas that people come up with are
based on the concept that you can tell code running as one application
from code running in another.

Until we have a good way of differentiating between applications
(whether by signature, SELinux security contexts, or something else),
ideas based on this concept have little value.

>> Obviously anything done in seahorse would be of absolutely no
>> consequence to any other password manager.
> 
> How often are keys requested from gnome-keyring ? How often would the
> user have to re-authenticate if every key request needs the user's ok ?
> I fear it will be to often. No UAC please

Yes again, I agree. gnome-keyring has had ACL based code for prompting
when secrets are accessed. Most people don't experience that code
because the distros have patched it out. It's such a hassle, and adds no
real security value.

> The security philosopy is right. If something/someone gets control of
> the user's account the battle is lost.

BTW, there are some ideas in various stages of research and
implementation, that could mitigate some of these security issues. I'll
enumerate a couple of them below.

Please, if anyone wants to discuss these further, open a new thread for
discussion on gnome-keyring-list gnome org 

 * Temporal access: Keyrings are unlocked for a certain amount of time.
   Think of how 'sudo' works... Whether idle time or definite periods
   of time.
 * Connection based access: An application connects to the daemon, a
   keyring is unlocked for that application until it exits/disconnects.
 * Application based storage: The gnome-keyring client library encrypts
   data for the application, which its then free to store however it
   wants. The client library stores a key for that encrypted data in
   the keyring.

Again, discussion welcome: New thread at gnome-keyring-list gnome org

Cheers,

Stef