On Thu, Dec 20, 2007 at 07:50:49PM +0200, Alan Barrett wrote:
> On Thu, 20 Dec 2007, Julio M. Merino Vidal wrote:
> > The problem I'm having is that the server refuses to open the 
> > authorized_keys file because one of its path components is a 
> > group/other-writable directory (that is, /tmp).
> 
> Last time I checked, sshd didn't do a full path walk, it just checked
> a few directories and files (I think only ~user, ~user/.ssh, and
> ~user/.ssh/authorized_keys), so putting your data one level deeper in
> the directory tree might help.

auth.c contains a secure_filename function that checks all the path
components, and that's the one used to open the authorized_keys file.

> 
> > And I think that's incorrect, because it should also take into account
> > the fact that the directory has the sticky bit set.  If that bit is
> > set, I don't see how being group/other-writable is a problem.  Can
> > anybody see any security implications of relaxing this permission
> > check to make sure that the directory is not group/other-writable or,
> > if it is, it is also marked as sticky?
> 
> If authorized_keys does not exist, but ~user/.ssh is group or world
> writable with the sticky bit set, then an attacker could create an
> authorized_keys file.  Similarly if ~user/.ssh doesn't exist but ~user
> is group or world writable with the sticky bit set.

Maybe the check is not enough then, and what I should ensure is that, at
some point in the path, the permissions are strict enough to prevent what
you mention (if sticky was set in a previous component).

Dunno, will bring this to the OpenSSH developers.

Thanks,

-- 
Julio M. Merino Vidal <jmmv@NetBSD.org>