Hi, well I've got the 'hang' of the chroot process for ssh. I'd like some opinions for "What you think is Better than chroot" for isolating server users home directories.

There's a lot'a documentation on breaking out of chrooted environments so I'd like to know if you know of a more secure process to employ!

Sorry if this is hijacking your thread at all, as I'd like to know the same question too...but could you post a link or something how u chrooted ssh users? (or did u just chroot ssh itself?)...

Lucky you: I was just reading about the new vserver package for newer Linux kernels! It allows you to partition off complete "virtual servers" where even a process running as root can't access the others. Check it out at http://www.solucorp.qc.ca/.

(Or on a Debian system, just 'apt-get install vserver' and read the docs...)

I have not tested Vserver, but I'm familiar with another way of placing restrictions on processes using the Grsecurity kernel patches.
If I have a quick glance at the docs I see a Vserver secures its runtime env in 5 area's (and adds 3 nw syscalls as well).
Area:
1. Filesystem: using default chroot() function.
* IMO there's no such thing as something better than chroot, only ways to secure ways chroot is handled.
You should know what the chroot() function does, and what it does not.
When called, chroot accepts an argument which will serve as the new root for the process: chroot(/somedir).
This should be preceded by a chdir(/somedir) to set the current working dir to match the chroot() arg in case the application itself doesn't support it. If a process with root privileges exists in the chroot (say by not dropping privs) a "mkdir out; chroot out; cd .." will get it out.
Other ways to get out of a chroot are pivot_root() (chroot inside a chroot), capget (leech privs from process outside chroot), fchdir (using a file descriptor of the chrooting process) and chmod (get setgid or setuid).
W/o reading the code I can not tell these issues (and other chroot restrictions) are addressed in Vserver like they are in Grsecurity.

2. Processes: using new function new_s_context to "shield" processes from "viewing" processes outside it's context
* Quite different from what GRsecurity does because it allows for a process to view other processes info when they are in the same "group".
GRsecurity can shield off /proc to have users view only their process information. Looking at the fchdir() stuff under chroot, you could argue if even loading /proc inside a chroot is a Good Thing.

3. Networking: using new function set_ipv4root to "chroot" processes to their network address
* Not even close. GRsecurity doesn't have this.

4. Super user capabilities: using LINUX_CAPABILITIES (caps intended)
* You could do this with some utilities w/o need for Vserver or GRsecurity. Beware tho, if you take away the right caps from root you won't even be able to reboot :-]
5. System V IPC shm selection using new_s_context.
* GRsecurity doesn't have this. It does incorporate a patch for making /dev/kmem read-only, and PAX to have some form of buffer overflow protection. This seems to break XFree86 4, Wine and the java runtime tho, the first 2 you don't need on a server and java, uh, well, isn't java way slow anyway? :-]

I'm not trying to pass the above off as an objective view on things and I'm not about to wrongly discredit Vserver, but you should know there's more than one way to make chroot behave better, more secure.

If you haven't already, read some of the refs below to make sure you know the do and don'ts like mounting proc, allowing symlinks to outside the chroot and allowing suetuid/setgid binaries:
How to break out of a chroot() jail, Simes 12 05 2002: http://www.bpfh.net/simes/computing/chroot-break.html, Using Chroot Securely, Anton Chuvakin, 10 02 2002: http://www.linuxsecurity.com/feature..._story-99.html and Silvio's doc at http://www.big.net.au/~silvio/runtim...m-patching.txt (he's got more interesting stuff around).

As a chroot shell I use Jail because it allows me to set up the basic skeleton for a jail relatively easy, so I only have to worry about tweaking like dir/file permissions and conf files. If I need to provide a login and shell, I'll use a modified Busybox binary with symlinks tweaked for that env, and sash if necessary.

HTH, and if I'm wrong somewhere anyone please correct me.

Jail project........I've heard of it, better check it out. Sure, I only chrooted SSH.......seams to work fine for ssh/sftp/scp.

Am using SSH2 and began trying the ssh-chrootmgr, but ended up simply adding users to the ChRootmgr declaration in the sshd_config2 file for /etc/ssh2 and adding only the necessary dependencies to the users home directory.....long process for first shot at it. Seams to resist my attempts to 'clobber' it....

I think I'm gonna' try out UnSpawn's ref : Jail project. Plus study the Grsecurity stuff.

Much thanks as this has given me insight to the WAY a process such as chroot() is implemented.

Any other thoughts / suggestions ?

Uhm, soz. Forgot to mention jail ain't a replacement for binaries doin their own chroot stuff, its for users.