Subject: Re: SSH and sticky mode in directories
To: Alan Barrett <firstname.lastname@example.org>
From: Julio M. Merino Vidal <jmmv@NetBSD.org>
Date: 12/21/2007 09:51:55
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.
Julio M. Merino Vidal <jmmv@NetBSD.org>