James Dennis
james@firstaidmusic.com
5.13.02
Table of Contents:
OpenSSL
OpenSSH
Patch
Building chroot
Testing
Conclusion
Links
OpenSSL is a free SSL implementation for *nix. An SSL is a Secure Socket Layer. SSL's basically allow for encryption of protocols in the payload while the routing information is still plaintext. Follow the inscructions in the included documentation to get this installed. I will not go into how to install this as it is widely documented and out of the scope of this document.
OpenSSH is a free SSH implementation for *nix. SSH stands for Secure SHell, which is a bit misleading as it is actually not a shell. It was originally developed to replace the cleartext telnet. It performs a public key exchange and immediately after begins an encrypted session using the methods of public key encrypted communication. It then generates a random symmetric session key and sends this securely over the previously established public key session and switchs to the symmetric algorithm and key for the rest of the session. This is done because public key crypto allows secure key exchange, but is much slower, so they securely transfer keys and switch to the faster protocol which has the added security of a randomly generated session key. Anyway... the point is, you get secure communication remotely with the power of issuing commands as if you were sitting directly in front of the computer (almost the same thing as telnet).
One of the interesting things about OpenSSH is SFTP. At the time of this writing, Sftp isn't actually a documented protocol. In fact, it isn't really a protocol at all. It's just a front-end to some confusing ssh commands and also attempts to mimic the look (well, sorta) and feel of regular ftp. When you sftp to a system, this is actually what's being run:
ssh2 -x -a -o passwordprompt "%U@%H's password:"
-o "nodelay yes"
-o "authenticitynotify yes"
server host
-s sftp
Sftp is cool because your able to transfer files and have everything ftp can do, but securely (no more sniffing passwords! w00t!). The only drawback is that it doesn't have the cool chrooting capabilities of wu-ftpd or proftpd (and probably others). So, as you can guess by the title of this document, our plan is to add that functionality.
So in order to apply the patch you will first need to retrieve the patch from
my site in the download section. You will also need to grab the source to OpenSSH from OpenSSH.org. Then apply the patch from whichever dir you untarred OpenSSH in with:
NOTE: You can now download a patched tarball instead and skip the patching step.
$ wget ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-3.2.3p1.tar.gz $ tar zxf openssh-3.2.3p1.tar.gz $ patch -p0 < /path/to/patch $ ./configure --with-md5-passwords (This may differ for you) $ make # make install
In case you are unfamiliar with what chrooting does I will explain it. Chroot stands for CHange ROOT, as in your root directory, not the root user. This is useful for restricting users to a particular area in the filesystem. You could set /usr/home to be the chroot directory and then users would see /usr/home as /. With this trick you can stop users from being able to see important/possibly vulnerable files/programs like the system crontab, setuid binaries, or any logs. Because /usr/home is now / to the users, you have to set their paths to be able to find the proper binaries to make their shell usable. What this means is, /bin/bash is not viewable to the user now that they are chrooted to /usr/home, so we need to make a /usr/home/bin/bash for the user to use. This is true for any commands the user will need, but, since the user is only sftp'ing files from one place to another, they only need a couple commands (rm, cp, mv, ls, etc) for this to work properly, which is the real beauty behind this sort of chroot.
Your probably wondering why this isn't done for everything on a unix system. Well, #1, setting up chroots can be difficult depending on what needs to be in the chroot, and #2, it's not perfect, it can be broken. The only way I know to break a chroot is to gain the privileges of another user who is not chrooted (please try to follow here, it may be confusing) or to do tricks with file descriptors (see the links below). If you login, the login process is run as root, so it can read /etc/passwd and authenticate you. You are then dropped /usr/home as your chroot so when the login command tells your login process to find /bin/bash, it will really be looking for /usr/home/bin/bash. Assuming it finds it, you are now logged in with /bin/bash as your shell. If su were available to the chrooted user, they could su to another, non-chrooted user, and be free of the chroot. So, it is for that reason that we must be sure to not have any suid binaries, or anything relating to elevating privilidges in an area the user can see.
Now to build the chroot. The minimum requirements for sftp to function on the systems I'm testing with (Gentoo 1.1a and Slackware 8) are:
/path/to/chroot/dev: null and zero (mknod zero c 13 12; mknod null c 13 2)
/path/to/chroot/bin: cp, ls, mkdir, mv, rm, rmdir, sh
/path/to/chroot/usr: requires a lib directory and a local/libexec directory
/path/to/chroot/usr/lib: ld.so.1, libc.so.1, libdl.so.1, libgen.so.1, libmp.so.2, libnsl.so.1, libsocket.so.1
/path/to/chroot/usr/local/libexec: sftp-server (can be copied straight in from /usr/local/libexec, but make sure you chmod +s if it isn't setuid already)
NOTE: I have been told (thanks to Brad Doctor, CISSP) this isn't necessary anymore. I can't account for all setups though and am not sure what setups would require this so try without setuid first!!
/path/to/chroot/home: This part is not necessary, but is pretty useful for containing real users in a mimic'd file system.
With all of that setup you should have a functioning chroot. To test, su to root and type "chroot /path/to/chroot /bin/sh". If this works, excellent! If not, DOH! As this is meant to cover doing a chroot in linux I will leave finding the rest of libraries required for the chroot to work up to you. If the chroot fails, it is most likely due to libraries not being in the chroot that are required and ldd will tell you those. As ldd isn't always perfect (solaris!), try strace also.
Now that you've built the chroot it's time to test it! Add a user that has a $HOME that is chrooted. Do what you normally do for adding a user, but make sure $HOME is /path/to/chroot/./home/username and their shell must be /bin/sh. Once you've done that, try ssh'ing in to the chrooted daemon (you did shut down the previous instance of ssh and turn on the new one right?) and seeing if that succeeds. If it fails, see this section for tips on building the chroot. If it succeeds, great, we'll try sftp. Now try sftp username@host and see if that succeeds. If so, great, if not, head back to this section again.
The process of building a chrooted sftp system is not difficult, it just takes a while to go through all the lbraries required to be in chroots. I have built this on solaris systems also, but had such a more difficult time that I decided to leave the differences between Linux and solaris to the brave souls out there as ldd lies on solaris (and I do mean lies) and I'm fed up with it. Make sure to read the methods of breaking out of chroots below so that you have a good idea of how secure what your building is. If you aren't careful with how you set everything up (home directories shouldn't allow executables to exist, period, and the users shouldn't have permission to write a file anywhere else) it's possible you'll get r00ted. Chroot's are not perfect security, but they are pretty good. Enjoy!
Gentoo Linux
Slackware Linux
OpenSSH
OpenSSL
chroot-break
other chroot-break tricks