Re: VFS for legacy apps

[Alexander Larsson <alexl redhat com>]

On Fri, 2007-02-23 at 15:03 -0600, Hans Petter Jansson wrote:
> On Fri, 2007-02-23 at 09:30 +0100, Alexander Larsson wrote:

> > So, when the app reads the data for recent files and stats it, or does
> > some other similar operation you'll pop up a dozen dialogs allowing you
> > to mount things like ftp.gnome.org again. You click "no" several times,
> > and two seconds later they all pop up again. Believe me, things like
> > this happen, all the time. I have to be extremely careful in nautilus
> > for example to never ever access (even get info about) things like
> > history or bookmarks except when the user explicitly browse into them,
> > otherwise we pop up dialog to left and right, when the user don't expect
> > this at all.
> 
> Isn't connection sharing in the daemon supposed to prevent this? If we
> have no low-level way to prevent it, I think we're in trouble anyway.

Not if you click 'no'. I.E. you had no intention to connect up with a
gazillion ftp servers from your recent files. I mean, I guess the daemon
could see that your trying to connect again to the same place you just
said no to and "magically" decide that this time you probably didn't
mean it. But such magic rarely work right.

> > I much prefer a system where the app can either just ignore the failed
> > stat (if it was an "unimportant" operation), or in case an open fails
> > display an error that the pathname couldn't be opened, with a pathname
> > that users can understand. Especially when said pathname is also likely
> > to appear in the user interface (in the file selector).
> 
> You can convert it to a URI on display, or even reach into a database of
> previously mounted user-named services to get a pretty name.

Ah, you could. An ideal app would (actually I guess an ideal app might
use gvfs instead of the fuse mountpoint). But acroread won't, nor would
most 3rd party apps. They will however likely show you the pathname that
failed to open.

> I agree that security is important, but the exploit would have to go
> something like this:
> 
> 1) You leave your computer on during lunch break without locking the
> screen (for cube slaves) or the door to your office (for execs).
> 
> 2) You work with your worst enemy and you don't know that he/she is just
> that, or you'd have fired her, quit your job or at least locked your
> screen.
> 
> 3) Said enemy knows how to make the already running gnome-keyring
> process give up its passwords (remember, if it restarts she'll need the
> master password that your keys are encrypted with). I can see this being
> done with significant gdb work.

gdb work? Why not make a tiny app (a few lines of python maybe) that
calls the gnome-keyring API and just *ask* it for the password.
gnome-keyring is after all specially designed to make it easy for apps
to retrieve passwords. In fact, you probably just need to click on
gnome-keyring-manager and select the right share in the UI.

> A) The shares are already mounted (gnome-keyring or not), so the
> attacker will never need the passwords.

I think you missed my point. Its of course possible already if you have
access to the logged in computer to access the shares. However, if you
extract the *password* you can use it later and on other computers to do
far more damage. In fact, if the user used gnome-keyring to store the
password for some sftp share its likely to be the users main login
password.

> B) Since gvfs keeps asking for passwords, you maintain a manual keyring
> on a postit note. The attacker finds the note.

There is always the risk of this. Its for this particular reason
gnome-keyring was designed. To avoid the postit-note keyring version. 
The idea is that you can use gnome-keyring to protect all the zillions
of passwords that todays web and computing world gives you and store
them in a safe way with one strong password and avoid using the same
password on all such sites. 

However, storing the really important passwords, like ssh login
passwords is not what its designed for. So, using gnome-keyring to
implement "process shared authentication" for shares is at worst
insecure (you store important ssh/smb password in gnome-keyring) or at
best weak (it doesn't work for shares with 'important' passwords).

> C) The attacker installs a prefab keylogger while you're out.
>
> The lesson is that you cannot protect yourself from password-extraction
> attacks against an unguarded, logged-in desktop, and in scenario B),
> which we are promoting by not using a keyring, the attacker doesn't even
> need to be logged in.

Security isn't an all or nothing thing. The fact that there are already
ways of attacks doesn't mean we should ignore other ways of attacks.
Especially if if the new ways of attack are "easier".

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's an old-fashioned ninja grifter haunted by an iconic dead American 
confidante She's a beautiful tomboy politician descended from a line of 
powerful witches. They fight crime!