chrooting/jailing transfer-only accounts

[Dan Astoorian]

On Fri, 24 May 2002 10:57:55 EDT, "Sandor W. Sklar" writes:
> 
> [...]  I'm just looking for a solution to the 
> problem I stated in the previous email.  Some people feel that this 
> is a "trivial" problem that can be solved without adding code to 
> OpenSSH.  If it is, I'm not smart enough to figure it out, and I 
> haven't seen any examples of such a solution posted to the list.

Ben said (and I agreed) that adding code to OpenSSH was the wrong
approach, but I don't remember anyone claiming the problem, let alone
the solution, was trivial.

In fact, I've been jumping up and down trying to point out how dangerous
it is from a security standpoint to do chroot()s carelessly.

If you don't need a general solution for many users (e.g., if you only
need a single chroot'd account for anonymous-scp), then a reasonably
simple program similar to this might be sufficient:

#define JAIL "/path/to/jail"
#define SHELL "/bin/sh"
int main(int argc, char **argv) {
    if (!chroot(JAIL)) {
	perror("chroot");
    } else if (!chdir("/")) {
	perror("chdir");
    } else if (!setuid(getuid())) {
	perror("setuid");
    } else {
	execv(SHELL, argv);
	perror("execv");
    }
    exit(1);
}

Note: the above is completely untested!  Use at your own risk.  The
wrapper is also not completely rigorous--it does nothing to try to
prevent fd's from outside the jail from being passed through it, for
example (not that this is likely to be a problem in most cases).  And it
puts a burden on the sysadmin to make sure JAIL is a safe place to
chroot() into (e.g., no system directories like /etc or /dev are
writable).

If you try to modify the above so that JAIL depends on the context in
which the wrapper is run, you're very likely to introduce security
holes.  Unless you know what you're doing, in which case you're only
moderately likely to introduce security holes.

-- 
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