Chrooting Shell and Apache [discussion]

T

The Prohacker

Verified User
Joined
May 23, 2003
Messages
103
Alright.. So I did some googling on chrooting/jailing shell and apache since this is a very demanded feature for DirectAdmin...

Going through many web sites I've found there to be really only two methods of doing a jailed shell..

1) Modifying the OpenSSH server to support jailed enviroments.
2) Making a shell for OpenSSH to use that forces a user into a jail after the login proccess...


There are some pretty big faults with both..

1) Modifying OpenSSH:
This would require patching the daeamon itself, and if that fails, after the restart the server would be almost unfixable remotely.. If you were with an unmanaged provider like RS your only real method of recovery would be a hard drive wipe.. So that makes this a rather risky option.. Even though with RPMs this could be made fairly standard.. There is a risk... But this is the most secure way of doing a shell as I see...

2) Jailed shell, this is more attractive and seems simpler.. But less secure... Usually to allow for a jailed shell sudo must be installed:
http://tjw.org/chroot-login-HOWTO/

You'll notice everyone has root privledges when they initally log in and they are chrooted down and pushed back into their user... This is all well and fine as long as the system is properly configured.. If a user were to edit the /etc/sudoers incorrectly they could give a user or all users full root privledge on their system...

I'm not quite sure how other control panels do their jailing.. I know a certain control panel has a jail shell method and I beleive he uses mount --bind for the method instead of chroot directly... But I'm not quite sure..

As far as chrooting Apache.. This isn't going to be much fun either.. To do a proper jailed Apache.. at least a single instance of Apache needs to be run at all times for each user thats chrooted.. And that would be fine for selected users on the system.. But could be hell if all users were chrooted by default...

Using mod_become could overcome a few things but this is also a security problem because it means Apache nees to run as root instead as the user 'apache':
http://www.snert.com/Software/mod_become/index.shtml

Any others have comments on all this that might be system administrators? I'm sure John wouldn't mind a few extra opions on this since its a feature thats really in demand...
 
Was just thinking.. One nice major feature of running an instance of Apache per user would be resource tracking.. We could track a users ram and cpu usage exactly in this case.. And limit accordingly... Each user would likely have their own httpd.conf.. Of course not editable by them directly.. But could limit the number of visitors per user and load apache modules on a per user basis..

Such as install mod_gzip/mod_php/mod_perl/etc per user in the admin panel by just checking it off...
 
The "process per user" would be nice... but.. 600 users per system isn't uncommon... 600 apache processes might a few too many, but we can keep this as a viable option.

John
 
Guess if the proccess per user jail was setup graphing usage would be very easy also so you can atleast show the user their cpu/mem/bandwidth usage...

We can graph per vhost usage right now with mod_watch.. But everything else would be great...


Oh why can't this be easier to do??? :D
 
Does the lack of such an environnement make directadmin less desirable? I'm looking for a secure solution and chroot seems to be a sine qua non condition.
 
Not exactly what you were asking for, but why not check out a VDS solution? I think vservers would probably do what you want. It would have several caveats you already mentioned (each user runs their own apache server for example), but it should keep users separated pretty nicely.

Just a suggestion I thought I'd throw out.
 
If SSH fails you could always log in via telnet to rescue the server as a last resort, restart ssh and then quickly change your passwords :)

Matt
 
interfasys said:
I'll use a VDS, but I want security for my users =)
Click to expand...

You can be secure and still use telnet in emergencies like this. First, I'd change your root password, then enable telnet before you make any changes to sshd. If there's a problem, you can telnet in and fix it. Either way, when you're done change your passwords back, and disable telnet.
 
You can chroot Apache 2.2.10+ easilly, just add ChrootDir to your Apache configuration.

e.g.:
Code: 
ChrootDir "/srv/apache_chroot"
 
You must log in or register to reply here.
Back
Top