Re: VFS for legacy apps

[Hans Petter Jansson <hpj novell com>]

On Fri, 2007-02-23 at 09:30 +0100, Alexander Larsson wrote:
> On Thu, 2007-02-22 at 14:51 -0600, Hans Petter Jansson wrote:

> > That's a good point. To make that suck less, you'd probably have to
> > 
> > - Immediately deny any access to unmounted shares.
> > - Pop up a dialog asking the user if it should be mounted (if the mount
> > metadata could be converted to a more display-friendly string, such as a
> > URI or even a chosen name, that would be great).
> > - Optionally mount it.

> 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.

> 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.

> > The bad part is that the application's "access denied" and the "I think
> > you're trying to mount something" dialogs would pop up simultaneously.
> > 
> > With gnome-keyring integration, this problem would largely go away,
> > though. In most cases, gvfs could fetch the auth information
> > transparently then go ahead and mount.

> Its unfortunate that due to todays stateless gnome-vfs that doesn't ever
> reuse server connections between processes we have to use gnome-keyring
> as a poor-mans connection-sharing. This is really not a good idea in
> general, as it means you tend to store all your passwords (like smb or
> sftp passwords that are often the same as your system password!) in
> gnome-keyring. Which is *not* recommended as good password hygiene.
> (i.e. anyone in front of your unlocked desktop, say when you're on
> lunch, can easily extract all your passwords from gnome-keyring. Handing
> out passwords is after all what gnome-keyring is designed to do.)
> 
> Lets not propagate such use further.

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.

It's a possible, but very theoretical threat. Here are some much more
realistic threats:

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

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

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.

Finally, the long-term security threat to the GNOME desktop that I'm
most worried about is trojans - but these would affect all
password-handling applications equally.

-- 
Hans Petter