Slashdot Mirror
Chroot Jails Made Easy
GonzoJohn writes "There are always difficult jobs to do as a GNU/Linux system administrator. Sometimes the difficulty lies in finding out how to do a particular job, not necessarily the job itself. This can be particularly true in the open source world where documentation can often take a back seat to implementation. But once in a while, you can stumble on a real gem that simplifies even the most difficult administration tasks. One such gem is the Jail Chroot Project. Linux Orbit introduces you to creating chroot-ed environments in this article."
I must have spent a week working through various docs trying to learn this, and most of what I read was either impossible to understand or just inaccurate. Finally I happened upon this, and I refer to it often. Here's the jist of it:
====================
Introduction
Jail Chroot Project is an attempt of write a tool that builds a chrooted environment. The main goal of Jail is to be as simple as possible, and highly portable. The most difficult step when building a chrooted environment is to set up the right libraries and files. Here, Jail comes to the rescue with a tool to automagically configures & builds all the required files, directories and libraries. Jail is licensed under the GNU General Public License.
Jail program has been written using C, and the setup script has been written using a bash script and perl. Jail has been tested under Linux (Debian 2.1 & 2.2, RedHat 6.1, 6.2 and 7.0 and Caldera Openlinux 7.0), Solaris (2.6), IRIX (6.5) and FreeBSD 4.3. Some people has contributed to jail with patches and ideas. Thanks to all of them.
Jail supports lots of interesting features:
Runs on Linux, Solaris, IRIX and freeBSD (tested) and should run in any of the flavours of these operating systems.
Modular design, so you can port Jail in an easy way.
Support for multiple users in a single chrooted environment.
Fully customizable user shell.
Support for multiple servers: telnetd, sshd, ftpd...
Easy to install thanks to the enviroment creation script.
Should work in any UNIX.
Ease of porting.
Allows run any kind of program as a shell.
An html version of the mailing list has been added to the web site. Now you can read all the user contributions, ideas and patches here.
Jail is a term taken from BSD.
/something bin, and /something becomes root direcorty (/) of run program. This program can't open for example /etc/passwd, because _real_ /etc doesn't exist in it's /. Chrooted program's /etc is in fact /something/etc. /dev) inside chroot, mount it, and ... voila! You have access to whole disk. Chroot is broken. Of course, you must have access for making file, but must chroot have.
In BSD, jail and chroot are two different things, althrough very similar. There exist two syscalls - jail() and chroot().
What's the difference?
Chroot is ordinary chroot, the same as in linux. You do chroot
But if you goot root priviledges you can easily break chroot. Just make a special file named 'hda1' beeing a device node (like those in
Jail is slightly different. It not only hold process in some directory. It's also *restrict* certain *syscalls*. So you can't mount anything, change network settings and some more. Jail is more restrictive and probably you can't break it even if you have root access in jail.
Jail, because of blocking syscalls, must have some help from kernel. Right now, there is a jail() in FreeBSD and probably NetBSD. OpenBSD don't have it - Theo says it's too complicated to be secure. Also Linux don't have jail().
If you want more information, browse FreeBSD man pages, avaiable online.
:wq
Although they are a step towards higher security, chroot jails are not infallible.
If there's a security hole in an application, it's still possible for an attacker to get root (but yes, they'll be confined to the chroot environment).
But then, under Linux, at least, the attacked will still be able to mount /proc, if they find a way of getting binaries into the machine, which will enable a number of possible attacks on the machine, by altering stuff under /proc/sys.
It may also be possible for the attacker to create device files (eg, /dev/hda) and write directly to the disk.
So, all in all, even if you're running in a chroot jail, it helps to make sure your apps are running as non-root, if you can. authbind is your friend.
-- Even if a god did exist, why the fsck should I worship it?
I don't. A UML installation normally has far more in the way of tools than a chroot-jail. if a cracker exploits a vulnerable daemon and gets into UML they have far more opportunity to do badness. If, on the other hand, they exploit a vulnerable chroot-jailed daemon then if it's well set up all they'll have access to is probably /dev/urandom and /dev/log - neither of which they can do any great damage with. UML is a great tool, but this really isn't the best way to use it.
Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.
The chroot environment is trivial to get out of if you're still running as root. Obviously if there's an exploit that lets you get root access even inside a chroot environment, then you can get out of that chroot environment.
The C source code is here.
now we need to go OSS in diesel cars
It supports very comprehensive policy creation to determine which system calls are allowed for a specific application. You can actually create your policies on the fly. A graphical popup will inform you about potential policy violations.
You can use it to restrict access to the file system, or allow only certain users to connect to the network or accept network connections, etc.
It is a great tool to improve the security of your system and available for GNU/Linux, NetBSD and OpenBSD.
I have set this up for use on one of our production servers. I haven't actually deployed the new box yet, but I have had a chance to play with vserver.
/home than the shells vserver. But I have qmail patched to use SMTP AUTH (with TLS of course), but for that to work I must share the passwd and shadow files from the shells vserver. Also, shells users will want access to their .procmailrc and .qmail, so I must mount the qmail vserver /home somewhere so they can access it. You can see that a typical production environment requires several relationships between vservers, which not only increases complexity but decreases security.
/proc is severely reduced. Users (including root) are bound by capabilities, so for instance you could prevent even root from opening raw sockets.
The concept is very nice, and in fact the implementation is also quite good. The biggest problem with vservers is the increased administrative overhead. This is of course to be expected, but in some cases it does require you to punch holes in your vservers. For example, I have qmail in a separate vserver, which uses a different
Still, the advantages are worth it. Unification (using hardlinks across vservers) is cool. vrpm lets you upgrade/install RPMs on all or selected vservers and lets you unify them after. Unfortunately there's no automated tool to non-RPM files, but that's not too hard to write.
Of course the kernel protection offered in vservers is another big plus that an ordinary chroot won't offer. Processes within vservers don't see each other, and
Vserver is definitely a good security tool.
Jason.
If someone can get a root shell, even if it's in a chrooted jail, they can get access to your whole system. This is possible because chroot wasn't really designed for security purposes, even though it's usually used that way. A root user can break out of a jail because:
1) chroots are not recursive. If I create a chroot jail inside an existing chroot jail, the outer jail disappears. Combine this with #2.
2) chroots will not let you open a file outside the jail. But if a file is already open when the jail is created, it will remain open and active.
So, if I can get a program to the victim's machine, I can open a file descriptor to the current jailed directory (fd = open(".", O_RDONLY)), mkdir a subdirectory, change into that directory, and chroot in it. Now I can do a fchdir(fd) to get out of the jail. From there, I will perform several chdir("..") calls to reach the real root directory, and exec a bin/sh. I now have a root shell to the whole system.
An ordinary user can't do the chroot's, but if there's already on open file handle pointing outside of the jail, they can usually break out, too.
For every post, there is an equal and opposite re-post.