Chroots? Jails!

Russel Coker blogs about securing a daemon using a chroot, and offsets it against SE Linux. He argues that SE Linux provides better security; no doubt.

One downside about SE Linux, however, is that it's far more difficult to configure correctly than a chroot. Setting up a chroot involves creating a directory, copying or bind mounting stuff in there, and then just using the chroot system call (either from a shell script or from a daemon). Setting up a non-standard daemon using SE Linux involves a very fine-grained process of allowing access to files and system calls that many people inexperienced with SE Linux will find too hard to do.

OTOH, he's right that it's possible to break out of a chroot, and thus a chroot system isn't totally safe.

This is why the FreeBSD developers implemented the jail system call since FreeBSD 4: basically a chroot on steroids, it implements a basic form of virtualization -- your "chroot" gets an IP address assigned, and jailed processes cannot communicate with processes outside the jail other than through TCP/IP or some other form of networking. Processes outside the jail can modify stuff inside it, of course (it remains a simple directory).

Of course, Linux doesn't have anything like the jail system call, but it's easy to set up a similar level of security using virtualization, in a way that is far easier for the uninitiated than when using SE Linux. That's not to say that jails or virtualization will give you the same level of security that SE Linux can offer (e.g., with jails or virtualization a user can still exploit a bug in a network-facing daemon to turn your machine into a zombie; SE Linux can make this impossible), but it's a different option.