Re: Fix for ssh-1.2.27 symlink/bind problem

[sgifford () TIR COM (Scott Gifford)]

Eivind Eklund <eivind () FreeBSD org> writes:

> On Sat, Oct 02, 1999 at 06:38:46PM -0400, Scott Gifford wrote:
> > I've put together a patch that lets ssh work around the OS bug that
> > allows bind to follow symlinks.
>
> There isn't general consensus that this is an OS bug.  We (as in
> FreeBSD) have installed a workaround consisting of blocking symlink
> following for the case, but we have not yet decided if we should make
> this permanent.

  It has always been my understanding of UNIX sockets that they need
not appear in the filesystem at all; whether inodes and directory
entries are allocated for them is an implementation detail.  The only
guarantee is that if one process is listen()ing on a socket, and
another process connect()s to a socket with the same path, they will
be talking to each other.

  This understanding comes in part from Richard Stevens talks and
books, including "Unix Network programming", which states "The 4.3BSD
implementation creates a file in the filesystem with the specified
pathname, although there are comments in the 4.3BSD manuals indicating
that future versions might not create these files." [1]

  From this assumption, it follows that a user program shouldn't have
to use filesystem operations to bind() to a UNIX domain socket.

  If this is not the desired behavior, at least a mechanism needs to
be provided which can instruct the kernel not to follow symlinks (like
the O_EXCL or O_NOFOLLOW flags passed to open(2) on BSD or Linux) when
binding to a UNIX domain socket.

  I don't think it is reasonable to expect user programs to jump
through this many hoops (in my SSH patch, I had to make a temporary
directory, stat the directory, chdir() into it, stat my current
directory, bind() the socket, rename the socket, chdir() back out of
my temp directory, and rmdir() the directory --- 8 additional steps,
and over 60 additional lines of C code) to avoid this.

  Further, I think that expecting software authors to realize the
implications of using bind() without these additional maneuverings,
with dire security consequences if they don't, is going to get us
nothing but less secure systems.

  If this behavior is going to be continued in future revisions of any
UNIX or UNIX-like OS, I think that this caveat should be well
documented in the bind(2) manual page.

> In my opinion, ssh is clearly the buggy party here; not following
> symlinks in the OS is just a workaround to avoid buggy programs
> causing problems.  We will only do this if we find that there are so
> few legitimate consumers of the behaviour that we can change it
> without problems - so far, we've only found one consumer, and it is
> only of historic interest, being a part of FreeBSD itself (related to
> /dev/log creation, IIRC) and only present in old versions.

  Perhaps, but it was certainly a subtle bug, and one I have not seen
before on this list.  The interaction between UNIX sockets and
symlinks doesn't seem to be specified anywhere, and at least Solaris
does not follow symlinks, so at any rate software which expects this
behavior is not likely to be portable.

  My instincts say that when faced with unspecified behavior, it is
probably wiser to choose the implementation that causes fewer security
risks, unless there is a good reason to choose otherwise.

  Just my 2 cents,

-------Scott.

[1] "Unix Network Programming," W. Richard Stevens.  First edition,
page 263 (section 6.3).