Re: GtkEntry memory vtable (to use non-pageable memory for passwords)



Matthias Clasen wrote:
> On Sun, Mar 1, 2009 at 7:47 AM, Sven Neumann <sven gimp org> wrote:
>> So perhaps as a start, try to make a list of the features that are
>> needed, or might be useful, in a password entry?
> 
> Some of the recently added new features are specifically for password
> entries, like the caps lock
> warning. A password entry looks just like a regular entry, and people
> expect to be able to use the features they know from other entries. I
> really don't think using a 'dumbed down' GtkEntry for passwords is the
> way forward (which is what started this discussion in the first
> place...). 

Adding more patches and special cases to GtkEntry is certainly easier
for me to contribute. But my concern was about the long term viability
of GtkEntry.

GTK+ already has two text widgets (GtkTextView and GtkEntry) and people
seem to be able to reconcile them.

But I'm not here to push either approach, simply to make some progress
in the right direction.

> Finally, it seems a bit silly to use a memory locked entry
> for your keyring password, when all the other passwords you enter
> (login screen, lock dialog, your online banking website) don't.

As a maintainer of gnome-keyring, seahorse and other security related
applications, I've been forced to give this topic a lot of thought. Yes,
it's a lot of complexity to justify, but I believe that it's worth it.

gnome-keyring is all about local computer security. That's the reason
for its existence. gnome-keyring tries mainly to prevent passive attacks.

I could go on and on about these topic, and the topics of passive vs.
active attacks, layered security, mitigation of attack vectors, etc.
Maybe I should put it on a wiki page. But here's just one of the risks
we're trying to mitigate:

gnome-keyring manages crypto keys (like SSH encryption keys). Most
people lock their crypto keys with a password, so that if someone steals
their computer [1] they won't be able to use their keys.

If gnome-keyring-daemon didn't use non-pageable memory to store the
passwords for those keys, then there's a very good chance they could be
written to the hard disk [2].

Security is a challenge, and local computer security doubly so [3]. It's
also a many layered challenge. It's no good throwing up our hands in
despair because "that application there" is a security risk in some way.

Will computer security every be perfect? I don't think so, but that
doesn't prevent us from trying. And using non-pageable memory is one of
steps in that direction.

Cheers,

Stef


[1] Yes I know about freezing ram chips to preserve their contents.
    That's an active attack.

[2] Search for passwords on a hard disk that you've had for years for
    passwords. I did, and damn there was a lot on there!
    If you do this do it carefully (ie: bash_history).

[3] For example see: SELinux, AppArmor



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]