Re: gnome-keyring Passwords freely available after login

[Yaron Sheffer <yaronf gmx com>]

Hi Stef,

I agree with Karl that this is a security problem that can be solved. I 
think your analysis is taking it too far.

Many people, myself included, have a screensaver that kicks in after a 
period of inactivity, but do not bother to lock the screen manually when 
leaving the room "for a minute". This may not be safe behavior, but it's 
very common.

Seahorse is available on many machines, and any snoop can come by and 
view the passwords. What Karl is suggesting (I believe) is that the 
Seahorse *application* should require the login (or keyring?) password 
to be entered, even though as an application, it already has access to 
the passwords.

I agree with Karl that this would provide real security benefit, even 
though a smarter attacker, or one who has more time, can install another 
application and access the same secrets.

Thanks,
Yaron
> Date: Sun, 12 Dec 2010 10:41:51 -0600
> From: Stef Walter<stefw collabora co uk>
> To: Karl<karl1982 gmail com>
> Cc: gnome-keyring-list gnome org
> Subject: Re: gnome-keyring Passwords freely available after login
> Message-ID:<4D04FB4F 1050908 collabora co uk>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 2010-12-07 22:13, Karl wrote:
> > I realize this is an ongoing and well-worn topic, but I want to weigh in
> > since I've been a frequent Ubuntu user for some time now.  I have a
> > problem with the way Gnome keyring handles passwords.
> I believe you're talking about the way seahorse allows you to see
> passwords. This is an ongoing problem that we're trying to figure out.
>
> I've done more research and thinking about it, and would like to explain
> the problem in a technical manner.
>
> Essentially what we want is an access control list. We want certain
> applications to be able to read the passwords (like the ones that need
> to use the passwords in authentication). In addition we want other
> applications not to be able to read the passwords (like key managers,
> eg: seahorse).
>
> In order for any ACL to work there must be what's called a 'principal'.
> The principal is the identification of the subject that is is trying to
> access the resource. When you go to a club for a night out, and the
> bouncer checks your name against the list, your name is the principal.
>
> On the linux desktop we currently have a hard time figuring out a
> principal per application. It's as if all the people going to the club
> somehow had the same name, or interchangeable names (and photo IDs).
> That would make the bouncer's job difficult.
>
> Ah, but you say, can't you use the application's full path as the
> principal? We tried that in the past, and it doesn't work for the
> following reasons:
>
>   1. Applications written in any sort of interpretted or VM based
>      language have a full path like: /usr/bin/python or /usr/bin/mono
>      or /usr/bin/java.
>
>   2. It's trivial to spoof the application path of a process by using
>      stuff like $LD_LIBRARY_PRELOAD
>
> So I don't know of a solid way to differentiate between applications
> running on the user's desktop. They all run with the same credentials
> (that of your unix login account), and they all appear pretty much the
> same to gnome-keyring (the bouncer).
>
> I'm not saying this is a deadend, but it is a difficult problem, given
> what we have to work with.
>
> Lastly, we want seahorse to be a manager of personal passwords (where I
> go into seahorse and store my bank card PIN) as well as passwords for
> other programs. For this reason there should be a way to see passwords
> in seahorse rather than just bullets. But is there a way in the UI we
> can find a good balance here?
>
> If anyone has possible solutions, then we can consider them. This is
> preferrable to simply restate the problem in different ways over and
> over again.
>
> I understand the
> > philosophy that a user shouldn't feel more secure than they really are,
> > and I agree up to the point where security is sacrificed for idealism.
> > If your car has separate door and ignition keys, you don't leave the
> > ignition key hanging from the hood ornament simply because no one can
> > open the door if you always remember to lock it.  The one time you
> > forget, someone drives off with your car.
> Analogies are lots of fun. FWIW the equivalent of leaving your keys on
> your hood ornament is leaving your screen unlocked when you're away from it.
>
> Cheers,
>
> Stef