Linked by Thom Holwerda on Sun 29th Jan 2006 16:04 UTC, submitted by Falko Timme
Privacy, Security, Encryption "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."
Order by: Score:
Great Info
by Smartpatrol on Sun 29th Jan 2006 17:23 UTC
Smartpatrol
Member since:
2005-07-06

Awesome info! Great way to corral Developers that think they are System Administrators and absolutely need root!

Reply Score: 1

RE: Great Info
by pojo on Mon 30th Jan 2006 04:19 UTC in reply to "Great Info"
pojo Member since:
2005-10-05

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.

Reply Score: 2

RE[2]: Great Info
by mikehearn on Mon 30th Jan 2006 10:39 UTC in reply to "RE: Great Info"
mikehearn Member since:
2005-12-31

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

Reply Score: 1

Is it secure?
by Ford Prefect on Sun 29th Jan 2006 19:12 UTC
Ford Prefect
Member since:
2006-01-16

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?

Reply Score: 3

Excellent
by Sphinx on Sun 29th Jan 2006 19:16 UTC
Sphinx
Member since:
2005-07-09

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.

Reply Score: 1

Multiple copies
by LB06 on Sun 29th Jan 2006 20:53 UTC
LB06
Member since:
2005-07-06

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.

Reply Score: 2

RE: Multiple copies
by MrEcho on Sun 29th Jan 2006 21:40 UTC in reply to "Multiple copies"
MrEcho Member since:
2005-07-07

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.

Reply Score: 1

RE[2]: Multiple copies
by s-peter on Sun 29th Jan 2006 22:49 UTC in reply to "RE: Multiple copies"
s-peter Member since:
2006-01-29

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.

Reply Score: 1

RE: Multiple copies
by ciphernaut on Sun 29th Jan 2006 22:56 UTC in reply to "Multiple copies"
ciphernaut Member since:
2006-01-12

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.

Reply Score: 2

RE[2]: Multiple copies
by phoenix on Mon 30th Jan 2006 02:38 UTC in reply to "RE: Multiple copies"
phoenix Member since:
2005-07-11

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).

Reply Score: 1

could someone modify rbash?
by ozonehole on Mon 30th Jan 2006 00:35 UTC
ozonehole
Member since:
2006-01-07

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"

Reply Score: 1

Use Permissions
by bottar on Mon 30th Jan 2006 08:25 UTC
bottar
Member since:
2006-01-30

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.

Reply Score: 2

RE: Use Permissions
by biteydog on Mon 30th Jan 2006 12:40 UTC in reply to "Use Permissions"
biteydog Member since:
2005-10-06

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!

Reply Score: 1