A question that is often asked is whether to use SE Linux or a chroot to restrict a program.
In Unix chroot is a way of running a program with a restricted set of directories available (it used to be merely a sub-tree but with bind mounts it can be any arbitrary set of directory trees). A chroot can be implemented in a daemon (it can call the chroot(2) system call before it drops it’s privileges) or by a shell script (through the chroot(8) utility). The disadvantages of a chroot are that root can escape from it, a chroot process can see the existence of non-chroot processes (ps and similar programs work in the same way in all chroot environments), and inter-process communication is not prevented. One solution to this is to have an enhanced chroot environment (which typically requires a kernel patch) where the chrooted processes can not run ps without restriction and have other limits applied to what they are permitted to do (there are several kernel patches that implement such restrictions). In the early days of SE Linux development I implemented similar functionality in SE Linux policy (here is the paper I presented at Linux Kongress 2002).
Configuring a chroot environment is inconvenient. If it is configured in the traditional manner (copying files to the chroot instead of bind mounting the directories) then old versions may exist in the chroot after new versions with security fixes have been installed in the main environment.
SE Linux provides better security than a typical chroot environment by controlling all interaction between processes. It provides more flexibility than an enhanced chroot environment by being configured entirely by policy and not requiring a kernel recompile to change the way it works.
I believe that the correct thing to do is to cease using chroot entirely and use SE Linux instead.
[…] SE Linux vs chroot » This Summary is from an article posted at etbe on Wednesday, August 22, 2007 A question that […]
“I believe that the correct thing to do is to cease using chroot entirely and use SE Linux instead.” might be valid for “chroot for security” use cases.
But this does not apply to some non-security use cases like having a sarge compilation environment on a sid machine.
While you make a good argument that SELinux is a better solution than chroot, chroot has the advantage of being portable to all Unix-like OSes. As a result, it’s not going to go away as an option.
chroot is kind of old school — what about SE Linux vs OpenVZ? You wouldn’t have to configure SELinux for your application, so you save some time there, but you have to configure your other machines so that if a guest gets rooted, it can’t get to anything else. Could be easier to do the OpenVZ route for a complex app, or at least if you spread the OpenVZ setup work across several apps.
http://www.grep.be/blog/en/retorts/russel_coker_chroots_selinux_jails
Wouter disagrees with me at the above URL. He points out that Jail is a standard feature in FreeBSD, what he doesn’t mention is that SE Linux is a fully functional and supported standard feature in Fedora, Red Hat Enterprise Linux, and CentOS. SE Linux is also a feature in Debian Etch, but it doesn’t work nearly as well as I desire (Lenny will be better).