“This tutorial describes how to install and configure OpenSSH so that it will allow chrooted sessions for users. With this setup, you can give your users shell access without having to fear that they can see your whole system. Your users will be jailed in a specific directory which they will not be able to break out of.”
Awesome info! Great way to corral Developers that think they are System Administrators and absolutely need root!
As far as I can tell, breaking out of a chroot jail is simple if you are root. You can just create a link to the main hard drive, and remount it at any point that you would wish to do so.
chroots are only good for non-privledged users, and even then there are probably ways of breaking out.
You can break out of a chroot if there is any program running as the same user as yourself that is not also jailed. Obviously, if you are root then there will always be a few programs running as root that aren’t jailed, so that’s trivial. A more subtle case is when you are chrooting the shell but not the SSH daemon instance that is connecting the user to it.
I’ll leave it as an exercise for the reader to figure out how you can use an unjailed program running as the same user to break out of the jail … it requires some sophistication on the part of the attacker but it can be done.
(edit: to be more precise, there needs to be an unjailed process that the user can send signals to – on Linux the rules are slightly different for suid programs so the SSH daemon instance being used to connect is probably not a problem)
Edited 2006-01-30 10:55
I read on the net that “chroot” is never a real secure way to jail someone in. With some C-skills one should be able to break out a chroot environment in every situation. The most simple ways to do this are easy to prevail, though.
Does anyone know more on this topic?
That is some good stuff there for anyone managing shell accounts to know. I think you’d need a /home/chroot/proc mounted too to get things working properly in your jail.
Is there a way to have chrooted accounts, without having one copy for every required bin or lib? On our server, we have more than a thousand user accounts, so chrooting them would be very costly in terms of disk space and ease of maintainability.
Lots of linking, ya it sucks, but it would work.
Just setup a master chroot user dir with all the links, then copy it for all the users.
That way when you update your system, everything within the chroot also gets updated.
It doesn’t seem that easy for me… First, newly created files and directories won’t appear in the chroot. Also, rpm does not overwrite (modify) files but replaces them with new ones. (Not sure but i’d guess tar/dpkg do the same). In that case, updated files are unlinked so the updates won’t be shared.
You could use Linux ververs or FreeBSD zones or the Solaris equivalent, some of them have a way of consolidating the virtual servers to one installation (I have only used Linux vservers, and didn’t try the consolidating feature). This could cut down on disk usage (beyone the first install) as well as provide more protection than filesystem chroot alone.
Another way might be to provide the required libraries configs and exes via an overlay filesystem (readonly of course) which could be ‘mounted’ as part of the login process, and utilise the GECOS feild the same way vslogin does: http://swapoff.org/LinuxVServer . This approach would have minimum impact on other systems such as mail and per user www
My apologies for my bad html skills.
Correction:
Solaris: Zones
FreeBSD: Jails
Linux: Virtual Server (but not the VRRPd/network HA virtual server project).
Using nullfs, null-mounts, or unionfs, you only need to install software once (not a lot of extra copying into the chroot trees needed).
The presented solution works, but sure seems overly complicated. I’ve long wondered why somebody doesn’t modify the rbash (restricted bash) shell to solve this problem. For those not aware of it, rbash prevents users from changing directories with the cd command. Unfortunately, that’s too restrictive – you want users to be able to cd within their own home directory, you just don’t want the cding into other people’s home directories. Couldn’t rbash be modified to do this? I wish I were a good enough programmer to hack this myself.
See “man rbash”
I was once in charge of building a web server that would hold hundreds of customer web accounts. The server being replaced had the problem that users could view each others directories when they logged in via ssh. Ssh access was important and couldn’t be dropped. I looked into using a chrooted ssh but instead went with a permission scheme that achieved what was needed. Users were unable to see into each others accounts or other places in the system they didn’t need to but Apache and MySQL worked as expected. In the end it made the users accounts more flexible because of the isolation. Oh, and it was easy to do and works on any Unix like system.
Permissions are there for a reason, just use them.
Looking back over setups I’ve done I’m surprised how often permissions have been the answer – and how they are rarely the first line of approach I’ve considered!