Re: VFS for legacy apps

[Hans Petter Jansson <hpj novell com>]

On Mon, 2007-02-26 at 11:13 +0100, Alexander Larsson wrote:
> 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.

A simple policy would be if the user says "no" to establishing a
connection once, then the answer will always be "no" until the user
explicitly mounts it. Similar to turning the "mount on login" option
off.

The daemon would also serialize the dialogs, and only show one at a
time. Then, further mount requests for a share that's already in the
queue, can be dropped.

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

If we can have something like a per-user fstab so the options can be
recovered, I concur.

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

Ah, I was thinking that gnome-keyring restricts access to a list of
specific binaries - but I forgot that you can add more once the keyring
is unlocked, and that gnome-keyring-manager will likely already be in
the list. There are still ways to mitigate this (and they would also
make what you deem "unimportant passwords" more secure against casual
intrusion):

- Make gnome-keyring-manager always require the master password when
it's opened. It makes sense because you rarely open it and when you do,
you usually close it before leaving the desktop - users are more likely
to see their own passwords in the UI and understand that it's insecure.
Any other applications that offer easy access to the user's keyring
would have to be amended similarly.

- Require the master password when you add to the list of allowed
binaries. Currently you have to yea or nay it, and we could add a
password entry to this dialog. This will also not happen often.

It's still just obfuscation, but with local attacks on a running,
unprotected desktop with an open keyring, that's really the best you can
do. I'm sure we can make it about as hard as installing a keylogger in
your .profile, and so gnome-keyring will no longer be the weakest link
in the chain.

In fact, I'd like to see these changes to gnome-keyring and
gnome-keyring-manager regardless of whether gvfs supports it.

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

I did not miss the point. A) is just one scenario where the attacker's
damage is limited to all your mounted shares, which is still
significant. I think "workplace sabotage" is more common than "workplace
identity theft", although I don't have any numbers on that, and I'm not
sure it matters.

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

I don't think users generally distinguish between "important passwords"
and "really important passwords". Also, it's not clear to me that file
server passwords are more important than your wireless networking
passwords, VPN passwords, IMAP/POP account passwords, etc. which are
currently being stored in the GNOME keyring by NetworkManager and
Evolution.

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

Sure it isn't. When you're inconveniencing the user in the name of
security, you need to compare the threat you're protecting against with
other threats of a similar nature.

As you point out, a local attack against gnome-keyring is a bit too easy
compared to other plausible attacks (esp. keylogger). Maybe we should
just make gnome-keyring harder to exploit, then?

-- 
Hans Petter