OpenSSH 3.2.2 released : chroot

[Dan Astoorian]

On Fri, 17 May 2002 12:05:07 EDT, Ben Lindstrom writes:
> 
> Out of interest why do you feel it's required to do chroot() at the
> OpenSSH level?

Playing devil's advocate: because chroot() needs to be done by a
privileged process...

> Why don't you invest time into a shell that does the
> chroot() for you?

...and such a shell would have to be setuid-root.

It would therefore also have to protect against a greater range of
attacks, because it can't assume it's being run from a trusted context.
For example, the program would need a way to determine what directory
it's supposed to chroot() to, and it would have to be a method that
users cannot subvert.

In that sense, it's in some ways easier to do it within sshd before
dropping privileges than it is to regain the privileges from a
setuid-root helper program later.

Having said that, I agree with Ben that a standalone product would be
very much preferable to complicating OpenSSH's daemon, even if it's
harder to do correctly.

> There is a chroot patch floating around already.  And I know people that
> apply it and use it happily.

I've seen a number of chroot patches floating around.  Some of them were
really awful: they did things like trust environment variables (or the
command line, or other user-manipulable sources), and could easily be
used to compromise a system.  I've commented on some of those patches on
this list in the past.

I don't know of any specific exploitable problems with the patch James
Dennis posted here; however, I'd feel a lot better about it, for
example, if it did basic hygiene such as doing a chdir("/") immediately
after the chroot(user_dir).  I haven't investigated that closely, but I
suspect it might be possible for a user to break out of the chroot()
jail by removing u=x permission from his home directory at the right
time, so that the chdir(pw->pw_dir) fails.

The patch also seems to declare two arguments to do_setusercontext() for
no apparent reason--from a casual inspection, the function only appears
to use them as local variables, and the caller passes in uninitialized
pointers for some reason.

I'd also feel more comfortable if there were sanity checks in the code,
to protect a sysadmin from misconfiguring a system in a way that would
allow a user to chroot() to an insecure place (e.g., somewhere that the
user could manipulate critical things like /dev, /etc, /usr, /proc,
/bin...)


At this time I know of no implementation of either an OpenSSHd patch or
a standalone shell which is trustworthy enough that I would feel
comfortable recommending it to anyone.

Ideally, I'd like to see someone who knows what they're doing write a
properly-implemented wrapper, and for that package to become the
solution that the OpenSSH team recommends in their FAQs.

I personally don't require the ability to chroot() from within an ssh
session like this, so I'm not motivated to write such a package, but if
someone else wanted to do so, I'd be willing to help with the design and
to help audit the thing for security problems.

-- 
Dan Astoorian               People shouldn't think that it's better to have
Sysadmin, CSLab             loved and lost than never loved at all.  It's
djast at cs.toronto.edu        not, it's better to have loved and won.  All
www.cs.toronto.edu/~djast/  the other options really suck.    --Dan Redican