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."
In the long run, though, I hope the standard aproach becomes User Mode Linux.
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
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....
moto411.com
This book will teach how to jail apache.
it would be nice to see, rather than just plain chroot with its own directories and such, a 'chmod jail', which acts as a symlink to other directories (no need to copy libs) yet makes certain alterations impossible for any user (even root)
-- 'The' Lord and Master Bitman On High, Master Of All
Note that there is a project that attempts to add jail-syscall-like functionality to the Linux kernel: vserver.
I haven't tested it yet, but it looks very promising.
Sig (appended to the end of comments I post, 54 chars)
The Medusa project allows the implementation of system call policies in Linux. Google for it. I think with smart rulesets; chroot and jail are all redundant. For example, denying untrusted user set*id access (toppled by smart fileaccess privileges) renders most "security" attacks useless for that user (he cannot cause any real damage other than DoS, which can also be stopped by implementing thread/fork timers for that user).
If this is possible, then this would diminish the value of even kernel level ACLs on files and processes. For example, grsecurity and LIDS.
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.
So, while chroot may be good, do not rely on it soley for security.