“Jailing is a mechanism to virtually change a system’s root directory. By employing this method, administrators can isolate services so that they cannot access the real filesystem structure. You should run unsecured and sensitive network services in a chroot jail, because if a hacker can break into a vulnerable service he could exploit your whole system. If a service is jailed, the intruder will be able to see only what you want him to see – that is, nothing useful. Some of the most frequent targets of attack, which therefore should be jailed, are BIND, Apache, FTP, and SSH. SSHjail is a patch for the OpenSSH daemon. It modifies two OpenSSH files (session.c and version.h) and allows you to jail your SSH service without any need for SSH reconfiguration.”
Using RSBAC Jail’s is a nice alternative. (http://www.rsbac.org)
it doesn’t require you to setup the chroot environment (no need to copy libraries and binaries) while providing a higher level of security than a simple chroot.
I enjoy that solution. It’s kind of awkward that I was just looking into a solution like this the other day. I ended up working around it, but I by far see the need for an easy way to do it.
A jail is alright, but again as xmv_ said, copying all of the binaries and libraries is a real frustration for each user you want to create a jail for. I really see a great use in this, as SSH is a nice way to do things, especially if you have a versatile system which can browse an SSH connection through a file manager or a web browser using the ssh protocol. Either way, I see great uses in this!
I can certainly understand jailing BIND, Apache, FTP, etc. When you access those services, you’re seeking specific, limited information. Restricting system access to that data is an obvious and logical security mechanism. But SSH is generally used to access the system remotely. What good does it do to SSH into a system if you can’t actually access that system?
Certainly, there may be instances where you only want to be able to SSH in and access a specific process or application. (If so, it would seem to me that that process or application might benefit from implementing a specific remote interface but that’s really outside the scope of this discussion.) But that seems to me to be the exception rather than the rule.
You are right, most people who run linux will want to have full access to the system but if You give a shell acount to someone You would like to give him only access to things he needs to access. If only admin is using ssh there is no need for chroot, the need comes when other users are using ssh.
Edited 2007-04-25 13:34
“[…] but if You give a shell acount to someone You would like to give him only access to things he needs to access. If only admin is using ssh there is no need for chroot, the need comes when other users are using ssh.”
I don’t think that would be a problem. File and directory permissions, such as rwx and user:group settings (to prohibit cd and any file access), along with $UID == 0 requirements for applications with high relevance to system security provide a means to restrict access. A user != root cannot override these settings.
(If I didn’t get your point right, please feel free to elaborate on this topic. I mention this as an excuse because english is not my native language.)
Jailed SSH sessions are typically used as a replacement for chroot FTP: allowing SCP, SFTP or rsync access to just a jailed area of a server for up/downloads, and nothing else.
This sort of patch is a Good Thing, because it helps put the nail in the coffin of FTP (and not a moment too soon).
Jailing ssh won’t work if you want to use it to grant users arbitrary remote access, but many ssh applications are more restrictive (for example, to allow remote users to access a CVS or subversion database).
Also, a chroot jail traps ordinary users, but if it turns out that there’s a root exploit, a root user can break out of jail. See
http://www.bpfh.net/simes/computing/chroot-break.html
With FreeBSD Jail you can have totally isolated operating system within host system and install/remove applications like in real standalone installation. You can even start multiple jails with different IP addresses for virtual hosting. This is common to have hundreds even thousands of jails running on one box and don’t worry about break-in/out. One huge benefit is that you don’t have virtualization overhead (emulation can take 20% of system capabilities) like with XEN/VMWare, whatever…
Unlike other fine-grained security solutions, Jail does not substantially increase the policy management requirements for the system administrator, as each Jail is a virtual FreeBSD environment permitting local policy to be independently managed, with much the same properties as the main system itself, making Jail easy to use for the administrator, and far more compatible with applications.
http://docs.freebsd.org/44doc/papers/jail/jail.html
Please remember that chroot() only restricts filesystem access, and nothing else. Chrooted processes can still access local TCP ports, affect non-chrooted processes running under the same user, run local root exploits, etc.