Re: How necessary is SSH_AUTH_SOCK?



On Sun, Oct 01, 2006 at 09:38:56AM -0500, Steven Elliott wrote:
On Fri, 2006-09-29 at 11:11 +0200, Markus Friedl wrote:
On Thu, Sep 28, 2006 at 12:17:17AM -0500, Steven Elliott wrote:
So my question is - Why doesn't ssh-agent default the location of the
socket file to some well known fixed secure location such
$HOME/.ssh/agent?

$HOME might be on a nfs server, so -a $HOME/.ssh/agent
is not the default.

How is having the socket file on an NFS server a problem? I know that
other applications do it, such as evolution / spamd:
/home/sle/.evolution/cache/tmp/spamd-socket-path-bz4CuE

On most platforms, this is a gigantic mistake, particularly if the
data is or could be sensitive (as is the case with authentication
credentials provided by ssh-agent). There are at least two problems
that I can think of off the top of my head:

1. In general, NFS does not encrypt the data that goes over the wire.
Thus authentication data supplied via the socket can be sniffed by
virtually anyone with physical access to the network, unless the
network admins go through rather a lot of pain to make it
difficult. Most simply do not. [Yes, switched networks CAN be
sniffed too. It's harder, but very possible, and really not that
much harder if you know/have access to the right tools to do it.]

2. In a lot of computing environments, people are allowed to have the
root password to their individual workstation. This is a mess in
an NFS environment, as it means anyone can read any files which are
exported to their machine, with the sole exception of any exported
files owned by root. So again, this would grant anyone and
everyone the ability to get your authentication credentials from
the socket.

If you're not using Kerberized NFS (and as yet odds are you aren't),
NFS should generally be assumed to be insecure for sensitive data.
With some pain it can be more secure (i.e. access controls on all your
switches, and making sure no one has the root password to any machine
which gets NFS mounts, per-user exports to user-specific machines,
etc.), but I've yet to see a single environment that does all of
what's needed to make it reasonably secure, simply because it's a
monumental pain to set it up and maintain it.

Also, I believe there are some nework filesystems which don't support
named sockets (AFS I believe, though I may be mistaken... CIFS? I
don't know but I'd guess not)... If the environment uses such
filesystems for home directories, it simply won't work at all. The
best place to put such files is generally in a directory in /tmp which
is owned by the user and set to 700 permissions, but the application
must still ensure that the directory tree has appropriate permissions
to prevent the removal or renaming of files leading up to that point
in the file system heirarchy, or else a malicious user could
potentially still replace the file with one they have access to.

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

Attachment: pgplu2v3UIicX.pgp
Description: PGP signature



Relevant Pages

  • Re: kern/129719: Panic during shutdown, tcp_ctloutput: inp == NULL
    ... A NULL pointer dereference here suggests that a second thread has closed the socket while it was in use by the first thread reconnecting it --possibly a race condition in the NFS client code, given that the connection wasn't actually connected yet? ... Try "info threads" and see if that shows up in an obvious manner -- perhaps the shutdown thread is in the VFS tear-down from boot? ...
    (freebsd-net)
  • Re: waiting on sbwait
    ... >> sbwait and nfsrcvlk, but i doubt that it's sockets that im running out ... > the socket to send, or for data in the socket on a receive. ... For example, the NFS client. ... > it's waiting for NFS network I/O, which could reflect a busy NFS server, ...
    (freebsd-hackers)
  • Re: Socket related code duplication in NFS
    ... Socket operations are handled multiple times in a very similar manner in these places: ... My recommendation would be to do this analysis against the new NFS client and server found in sys/}, which is the NFSv234 implementation. ... packets together before they are processed. ...
    (freebsd-current)
  • [PATCH 27/28] nfs: enable swap on NFS
    ... Implement all the new swapfile a_ops for NFS. ... SOCK_MEMALLOC and run socket reconnect under PF_MEMALLOC as well as reset ... int err, status = -EIO; ... goto out; ...
    (Linux-Kernel)
  • [PATCH 31/33] nfs: enable swap on NFS
    ... Provide an a_ops->swapfileimplementation for NFS. ... NFS socket to SOCK_MEMALLOC and run socket reconnect under PF_MEMALLOC as well ... goto out; ... +config NFS_SWAP ...
    (Linux-Kernel)