Chroot Jails Made Easy 87
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."
This is a great find! (Score:5, Informative)
====================
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 [uc3m.es].
Re:This is a great find! (Score:5, Informative)
Hi to everybody !
I'm Assman :) Yes, Jail works on all of these platforms!. I mantained Jail for about one year,
If you see the page, Its pretty outdated. I want
to update it more frecuently, but we have some
'technnical dificulties' (mainly, I need a new
site to migrate Jail)
Now I have new plans for it: support more platforms, fix the installation bugs, migrate all the scripts to python (yes, python rocks!) and support program dependencies in order to install all the software (not only one binary or script)
Thanks to everyone for your feedback and new ideas.
- Juan M. Casillas
PS: Please send me all your feedback in order to improve jail!
Re:This is a great find! (Score:3, Funny)
Gues he must really like it in jail!
Oh, come on. I'm kidding. Relaxez-vous.
what do I do with it? (Score:4, Interesting)
In the long run, though, I hope the standard aproach becomes User Mode Linux.
Re:what do I do with it? (Score:5, Informative)
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.
Well set up? (Score:2)
Re:Well set up? (Score:2)
Re:what do I do with it? (Score:5, Informative)
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.
Why CHROOT JAIL? (Score:5, Informative)
Re:Why CHROOT JAIL? (Score:1, Informative)
Re:Why CHROOT JAIL? (Score:3, Informative)
Re:Why CHROOT JAIL? (Score:1)
Re:Why CHROOT JAIL? (Score:2)
Re:Why CHROOT JAIL? (Score:1)
Re:Why CHROOT JAIL? (Score:2)
Local access at the terminal/user level is secure for any pure capability system (properly configured of course).
plan9 can't (Score:2)
File access is via a dedicated server
Authentication for file access to the fileserver is from a dedicated server.
Users log into a third group of machines - CPU servers.
Local access means nothing. You can't escalate your privileges because there are none to escalate to.
Bloody BOFH (Score:3, Funny)
Then he formatted my drive
Then he garbled my project
But.. I am *not* going to let him put me in jail too! Rise ye users. This is a conspiracy by all admins to jail us. they are violating our DMCA RIAA CIAA BIDA
Cue the Fat Boys (Score:1)
In jail, In jail because we failed!
jail != chroot (Score:5, Informative)
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.
Re:jail != chroot (Score:1)
Theo thinks that things can be secure only if he can understand them ?
Well, at least he isn't putting something in the kernel that he doesn't understand. :)
Re:jail != chroot (Score:2)
Well, duh. Properly securing a system absolutely requires that you understand it completely.
john
You don't even need a device. (Score:2)
You don't even need a device to get out of chroot. See my other comment [slashdot.org] to this story.
Re:jail != chroot (Score:2)
I disagree with that. But I do agree with the rest of what you wrote. Chroot is not broken, but it is however often used for the wrong job. Chroot is intended to be usefull for some system installation, system maintainance, and some software testing. For those purposes chroot works nicely. But using chroot for security purposes can be broken. Though chroot is not intended to be a security feature, it can in some cases help security. Running a daemon with a different root only helps if the daemon does not run as root, in that case we can prevent it from accessing a lot of devices and suid executables, which could potentially contain root exploits. So chroot cannot keep root inside, but it can help preventing another user inside from finding the root exploit he needs to get out.
Real jail for Linux (Score:3, Interesting)
Note that there is a project that attempts to add jail-syscall-like functionality to the Linux kernel: vserver [solucorp.qc.ca].
I haven't tested it yet, but it looks very promising.
Re:Real jail for Linux (Score:4, Interesting)
than jail (2 syscalls instead of one). It also builds on
linux capabilities, so you can control the level of
privilege a virtual server has (root in a vserver).
Because of its generality, it was far easier to package
solutions out of it. vserver is already in production today.
Some ASP offers virtual servers to customer.
Quite frankly, once you have tried vservers, it changes the way you work (for the better). Here are some advantage:
-More secure. A vserver can't break into the root
server.
30-40megabytes of disk space.
a production server running side by side with a
clone so you can test upgrades is easy and safe.
to another without reconfiguration.
To say that vserver is promising is
Re:Real jail for Linux (Score:4, Informative)
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.
Re:Real jail for Linux (Score:1)
Convert your system authentication over to an LDAP database, install the LDAP PAM libraries, configure qmail for pam -> LDAP authentication, and then connect to your login database over the loopback network connection.
I've never actually done this, but AFAIK it should work.
Re:jail != chroot (Score:2, Informative)
Vserver project for linux does
have an equivalent of FreeBSD jail():
http://www.solucorp.qc.ca/miscprj/s_context.hc
Re:jail != chroot (Score:2)
OpenBSD has systrace [umich.edu] to restrict system calls, as does NetBSD and it is being ported to linux as well. there exists a systrace implementation on NetBSD which eliminates all setuid/setgid binaries - http://mail-index.netbsd.org/source-changes/2002/1 0/12/0006.html [netbsd.org]
it almosts seems that secure unix systems want to be capability systems.
Feature Request: RPM Integration (Score:4, Interesting)
From the site:
Again, not to minimize the outstanding work here, but what if I want to create chroot jails for the LAMP class I'm teaching (I'm not really, but this seems like a cool application) so they can all have their own Apache installations? It sounds like chroot will know to move the httpd binary and the required shared libraries, but what about the rest of the admin shell scripts, server root, shared icons dir, mime types file, etc.?
Then what happens if I want to upgrade? My guess is a fair amount of bootstrapping needs to be done in the new root....
What might be really cool is for addjailsw to be RPM-aware so I could do a addjailsw mod_ssl-2.8.7-6 which would get a list of necessary files and package dependencies and install them in the new root and update the RPM DB in the new root as well.
Maybe just wishful thinking....
Re:Feature Request: RPM Integration (Score:4, Interesting)
Hello
Yes. This can be the right approach to this. If you have all the packages ready for install into jail, you can jail a whole system :) But when you change the original package, you need to re-package the 'jail' version.
But, lets go one step far: what about to create a script that generates the jail package ? this shouln't be so difficult: jail explores the binary files (and a dry run) in order to extract the 'dependencies' of this file. But you can explicity say what are the dependencies (e.g. you can tell the packager that apache requires the bin/* files, the conf/* files, and the libexec/*, plus all the required libraries (found when jail explores all the binary and library files)
I think on this, it looks useful!. For now, what wants to create a .deb or .rpm packages for jail so it can be included in some distros
Just one problem... (Score:5, Informative)
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 [debian.org] is your friend.
Re:Just one problem... (Score:2, Informative)
You don't need /proc or even a device to get out of chroot. Just hang on to the current directory and move the chroot to a subdirectory below you. Then repeat chdir("..") until you are back at the real root and do chroot(".") and voila, you're out. The code is here [google.com].
Re:Just one problem... (Score:5, Informative)
A good example of this is in the case of BIND9. One starts the name server (as root), which binds to the socket, and then chroots and drops priviliges to that of the named user. If BIND is compromised the attacker finds themself in a chroot jail as user named with only read access to the files they can see.
Chroot-jails do not provide complete protection for programs that run as root (at least not on machines that don't implement the jail() system-call, ie most *nix OSs). They are still, however, extremely useful.
That's neat (Score:4, Insightful)
Like usual, all you need is access to a compiler, and you can make a jailbreak. In fact, there's a whole guide to it here:
http://www.bpfh.net/simes/computing/chroot-break.
If the whole jail resided in its own actual virtual Linux machine, where nasty things cannot break the account, just the session, they would be quite a bit more effective.
Re:That's neat (Score:2)
You can use User Mode Linux [usermodelinux.org] to do that.
Re:That's neat (Score:2)
Except that UML often gives the attacker enough that they don't need to bother breaking out of it. These days, nine times out of ten, the attacker has compromised your box in order to use it for a DoS net. UML gives the attacker all the tools necessary to do this without any need to break out of it at all.
Re:That's neat (Score:1)
Re:That's neat (Score:1)
have chrooted process with less capabilities
so they can't break out. For example, they can't
use mknod nor write to
mount. So even as root with a compiler, you won't
break the chroot (all the tricks have been tested).
http://www.solucorp.qc.ca/miscprj/s_context.hc
Apache in Jail (Score:1, Interesting)
I mean you've got to have a theme. (Score:1, Redundant)
http://www.gsyc.inf.uc3m.es/ ~assman
Re:I mean you've got to have a theme. (Score:5, Funny)
Yes !
In the beginning, I want to call myself the assembler man, but I have a very poor english at 14' (I'm spanish) and I didn't know what 'ass' means XD. But yes, I'm assman.
Re:I mean you've got to have a theme. (Score:4, Funny)
Sooo Assman...
Does your code have any back-doors?
sorry, it had to be said.
Re:I mean you've got to have a theme. (Score:1)
chmod jail? (Score:2, Interesting)
Re:chmod jail? (Score:2)
Get out of jail free! (Score:5, Informative)
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 [google.com].
Re: Old but effective (Score:4, Insightful)
It is rediculous to do a Maxwell Smart and put 10 locks on your front door when the window is wide open. You are always better to rely upon a locked box, inside a locked box, inside a locked box etcetera, Rather than OUMF lock!
OUMF??? you say (new proposed acromyn)...
Just think of Arnie in Predator when he says to the alien "You're one ugly mother f......"
.... lack of documentation? (Score:2, Insightful)
This can be particularly true in the open source world where documentation can often take a back seat to implementation.
*
I dont know to what degree this is meant, but I would never find myself stating this alone. I think open source generally has incredible documentation. The only comparison to open source is closed source, and I don't think there is much of a question of which one is stronger at documentation. Even when I do find closed source documentation, it is rarely verbose enough. Another strong point to open source documentation is that it is only getting better. While most closed source development just leaves release info and install info (often just informing the location of files), open source documentation projects are often an undermovement to projects themselves. I don't deny there are exceptions, like this article and some other projects, systems, etc (particularly very small ones), but if it wasnt for the incredible open source documentation out there, that is so persistently provided that I always expect it, then I wouldnt have ever been able to detach myself from the closed source hells I have been used to.
Re:.... lack of documentation? (Score:1)
My own pet grump in this regard is GTK/GDK, where it would appear that they did documentation for 1.0 about 5 years ago, then gave up halfway through, but carried on coding the next version anyway. Now they're on 2.0, and version 1's documentation is still unfinished. True, it's free software, they don't owe me anything, it's not like they're getting payed for it; but it's asking a bit much to expect me to want to use the thing so badly that I'd go out of my way to figure out all the ins and outs of the damn thing, to work out what they, who know all about it could have written down for all the world to see, which would have spared lots of people time that could have been better spent- so I've since given up trying to code stuff with GTK. Yes, having said this, a pretty huge number of people seem to have written things with GTK, but perhaps what they needed had been documented, or perhaps they were far more patient. Perhaps they were more "leet" than me. Who knows.
Now, rant over, don't get me wrong- as I said, that's just an example of how I feel documentation is often dealt with in free software, it's hardly particular to that project. Also, don't anyone go making out that I'm claiming that GTK/GDK is "bad software", because I'm not. I just feel that being told "read the source" is a fscked-up response for people to give when you need documentation.
Oh well, perhaps we're both looking at different software, or maybe I'm just a miserable bugger. shrug
NB-I still prefer free (as in GPL) software
System call policies (Score:4, Interesting)
Re:System call policies (Score:2, Informative)
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.
virtual users (Score:1)
Does anyone know of a similar method that can authenticate users out of a virtual user database?
Re:virtual users (Score:1)
I personally run an apache/postfix/courier-IMAP/pure-ftpd server where all users are stored in a MySQL database. Courier-IMAP and Pure-FTPd both query the database directly, and Postfix does SASL-based SMTP authentication. SASL uses IMAP to perform the authentication, which ties it back to the same database. Users can upload web pages to an appropriate directory, which I manually direct Apache to serve as a specific website. Pure-FTPd handles the chrooting itself.
If you are free to choose the programs you will be running to support a specific task, you should be able to find one that supports MySQL-based virtual users without too much hassle.
Is IA32 any less secure? (Score:1, Interesting)
If this is possible, then this would diminish the value of even kernel level ACLs on files and processes. For example, grsecurity [grsecurity.net] and LIDS [turbolinux.com.cn].
BTW I just followed the instructions listed in another comment in this discussion in order to break out of my own chroot instantly. Wow. :-/ Well at least it's still fine as long as there's no way to gain UID 0 privilege inside a chroot, such as if the network daemon runs as non-UID0 and there are no userspace tools in the chroot.
Re:Is IA32 any less secure? (Score:2)
chmod is nice... (Score:2, Interesting)
So, while chroot may be good, do not rely on it soley for security.
This has been taken even further (Score:1)
"Chroot jails made easy" (Score:1)
Or so I thought.
SECURITY IS NOT ABSOLUTE! (Score:2)
Yeah, chroot is not absolute. Neither is anything else. But, it's a great way to make sure that your clients don't see anything they aren't supposed to.
Combine chroot with SSH-only connections, and you have a real step in the area of security and/or privacy.
Again, read the subject, SECURITY IS NOT ABSOLUTE! But any step you make to prevent unwanted activity is a step in the right direction. Enough thwarting of "bad" behavior means the black hat will quit or look elsewhere, and that means you've won.
Security is not about absolutes; it's about risk management. Only idiots think that something is "secure" or it's "not". Chroot is a valid tool in the direction of more secure.