feature request & patch submit: chroot(2) in sshd

[Hank Leininger]

On 2000-10-29, Birger Toedtmann <birger at takatukaland.de> wrote:

> On Sun, Oct 29, 2000 at 01:52:58AM -0500, Hank Leininger wrote:

> > Aren't you missing a 'chdir("/")' in there?  Else you leak '.'
> > outside the chroot jail.  (Unless a chdir is guaranteed to be done
> > between here, and when user processes get control?)

> Well, right beneath this code session.c switches uid/gid and then sets
> the environment. $HOME is set to pw->pw_dir (already set to "/") and
> $HOME/.ssh/environment gets its share. After this, the chdir() is
> made....

Ah.  OK, so there is a chdir() guaranteed.  Although you raise a good
point:

> ...hmmm - do you think one might be able to fool .ssh/environment into
> leaking information about "."?

I'm really not sure.  But for warm-and-fuzzy, obviously-correct behavior,
I'd vote for an explicit chdir(pw->pw_dir) right after pw->pw_dir = "/" as
you suggest.  Consider the alternative -- we might audit the behavior of
.ssh/environment usage now and deem it safe, only to have others decide
later, for whatever seems like good reasons at the time, to break our
assumptions wrt its safety in the face of things getting reordered, odd
custom shells, forced commands from authorized_keys, scp's, and whatnot. 
Better IMHO to have the fact that it is Done Right localized and hard to
break accidentally by other subtle means.

Hm.  For instance... $HOME/.ssh/environment processing, and then chdir, are
done after dropping privs.  Which the chroot() code itself obviously cannot
be, as one needs to still be e?uid=0 to chroot(2).  What if we are told to
chroot to a directory for which the current user has no execute permission?
The chroot will succeed, but the later chdir will fail--and it will not
"know" that failure has security implications, it will only think that a
boring erorr has occurred, and the admin is dumb.  Yes, this is a
wetware-bug if it is one at all (and a stretch in general; if one can't
execute '/', not much will work beyond that point, including accessing
$HOME/.ssh/environment =), but this kind of non-obvious consequence is not
good.

> If this could be done you are quite
> right about doing the chdir() right here, so maybe it should look like
> this: 
[snip]
> Alas: I did not manage to get $HOME/.ssh/enviroment into this kind of
> "."- intelligence-gathering, just got me curious. Any suggetions?

Well, if I understand you correctly, a simple test:
$ head -c16 .ssh/authorized_keys ;echo
from="localhost,
$ echo 'HOME=.' >.ssh/environment
$ ssh localhost echo \$HOME