You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Davide Giunchi <da...@libero.it> on 2002/12/02 18:58:55 UTC
[users@httpd] Re: chrooted cgi-bin
This is what i was searching before using apache in a real-world mass
VirtualHosting system.
The direct answer to your question is: sbox, you can search for it on
freshmeat.net .
I've used it, but to permit a little scripting to the users via a chrooted env
you must compile a little chrooted env that use ~ 20Mb for each VirtualHost
(libc6, bash, perl with some modules), so you will loose a lot of space.
And then for php? woudn't you like to chroot php too? so you will need to
compile php too, so other space is needed, minimum other 10Mb.
Second sbox is a program of 1997, no other's upgrade since now, it works but
do you trust it for the future? i will use it only if i've a good C and
suexec.c internal knowledge.
Last but not least every cgi-bin (or php) will need a chroot system call(),
and this is not a little ovevrhead on a big system.
So after little test i've found that i can grant a big security running wole
apache on a chroot, protect every user's documentroot with unix permission
and using suEXEC.
In a chroot you can deny every users to look at /etc/passwd and other
important files, and with simple permission you can permit to every user to
look only at his document root and not other's users document, yes it can
surf on the filesystem but with a chroot you have little files so you can
control it quickly with unix permission.
Regards.
--
Davide Giunchi.
Membro del FoLUG (Forlí Linux User Group) - http://folug.linux.it
GPG Key available on http://www.keyserver.net
Fingerprint: 4BFF 2682 6A58 ECFE 071B A1A4 F2A3 9EFA 6494 81FD
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: chrooted cgi-bin
Posted by Alain Fauconnet <al...@cscoms.net>.
On Tue, Dec 03, 2002 at 10:49:29AM -0600, Chuck Pierce wrote:
> btw, when you are setting up loopback filesystem mounts are you setting up nfs
> mounts?!?! Wouldn't that take up a BUNCH more memory that just doing "ln -h
> /home/chroot_usr /home/somedomain.com/usr"?
Loopback != NFS. Call this 'local file system' (lofs) if you live in a
Solaris world. AFAIK they seem to use very little memory.
The users home directories and the base of the chrooted bin, dev, lib
etc. live in two separate filesystems, so a hard link just won't work
in my case. Also, users can delete hard links and thus screw their
environment. They can't delete mounted lofs mount points.
_Alain_
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: chrooted cgi-bin
Posted by Chuck Pierce <ch...@onyxsys.net>.
So basically between using the perchild module (for server side include apps
like php, etc) and Sbox (using mod_rewrite) I can have an virtual host look/feel
like it's the only thing on the box. All this with minor excess system resources,
right???
btw, when you are setting up loopback filesystem mounts are you setting up nfs
mounts?!?! Wouldn't that take up a BUNCH more memory that just doing "ln -h
/home/chroot_usr /home/somedomain.com/usr"?
- Chuck
On Tue, Dec 03, 2002 at 09:38:03AM +0700, Alain Fauconnet wrote:
> Just my 0.02 Euro:
>
> > As for file space is concerned, I can setup a chroot_usr directory that I hard
> > link to the users home directory as usr. So when they reference /usr/bin/perl it will
> > work (and I won't need a bunch of copies of perl).
>
> Hard links or loopback filesystems mounts. I use the latter because I
> find them more transparent and possibly more robust.
>
> >
> > Now, my question is this; how much overhead were you talking about for the chrooted
> > system calls? I was under the assumption that it just took up more memory (to
> > exec another shell).
>
> Exec another shell? Pardon? This is not needed at all. The chroot(2)
> system call just does that: changing the root location. It doesn't
> fork a new shell. Sbox calls chroot(2) just before exec'ing the CGI
> script, so there's no extra process overhead. I can't comment about
> the overhead of chroot itself, but my experience on a quite busy web
> server is that the load hasn't significantly increased after I began
> using Sbox.
>
> > > And then for php? woudn't you like to chroot php too? so you will need to
> > > compile php too, so other space is needed, minimum other 10Mb.
>
> Sbox only applies to CGI interface, which PHP normally isn't unless
> you compile it this way (and break a lot of PHP code).
> PHP has its 'safe mode' the achieve roughly the same effect (I *do*
> understand that there are a lot of differences).
>
> > > Second sbox is a program of 1997, no other's upgrade since now, it works but
> > > do you trust it for the future? i will use it only if i've a good C and
> > > suexec.c internal knowledge.
>
> Good point, although the design of Sbox is simple and robust enough so
> that no updates are really needed. The CGI interface is not likely to
> change.
>
> Sbox's main gotcha is its file size resource limitation. It will limit
> the size of its own log file and Apache's log files, which makes it
> for an easy DoS attack or problems for lazy sysadmins not rotating log
> files!
>
> Greets,
> _Alain_
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: chrooted cgi-bin
Posted by Alain Fauconnet <al...@cscoms.net>.
Just my 0.02 Euro:
> As for file space is concerned, I can setup a chroot_usr directory that I hard
> link to the users home directory as usr. So when they reference /usr/bin/perl it will
> work (and I won't need a bunch of copies of perl).
Hard links or loopback filesystems mounts. I use the latter because I
find them more transparent and possibly more robust.
>
> Now, my question is this; how much overhead were you talking about for the chrooted
> system calls? I was under the assumption that it just took up more memory (to
> exec another shell).
Exec another shell? Pardon? This is not needed at all. The chroot(2)
system call just does that: changing the root location. It doesn't
fork a new shell. Sbox calls chroot(2) just before exec'ing the CGI
script, so there's no extra process overhead. I can't comment about
the overhead of chroot itself, but my experience on a quite busy web
server is that the load hasn't significantly increased after I began
using Sbox.
> > And then for php? woudn't you like to chroot php too? so you will need to
> > compile php too, so other space is needed, minimum other 10Mb.
Sbox only applies to CGI interface, which PHP normally isn't unless
you compile it this way (and break a lot of PHP code).
PHP has its 'safe mode' the achieve roughly the same effect (I *do*
understand that there are a lot of differences).
> > Second sbox is a program of 1997, no other's upgrade since now, it works but
> > do you trust it for the future? i will use it only if i've a good C and
> > suexec.c internal knowledge.
Good point, although the design of Sbox is simple and robust enough so
that no updates are really needed. The CGI interface is not likely to
change.
Sbox's main gotcha is its file size resource limitation. It will limit
the size of its own log file and Apache's log files, which makes it
for an easy DoS attack or problems for lazy sysadmins not rotating log
files!
Greets,
_Alain_
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: chrooted cgi-bin
Posted by Chuck Pierce <ch...@onyxsys.net>.
The problem is not just for security (although it does help), but really for
dumb users.
I have setup like this:
One directory contains all of the "home" directories for all of the virtual
hosts. Each home directory contains three sub directories (web, cgi-bin, data).
The web folder is for the html/images, the cgi-bin is for their cgi scripts, and
the data directory is for any data files, templates, etc that any of the cgi
scripts might use.
I'm using proftpd to have users chrooted into "/path/to/website.com", so all
they see are the web, cgi, and data directories. Because of this when they put
data files in their data directory, they are attempting to open /data/somefile
instead of /path/to/website.com/data/somefile (or even ../data/somefile). If I
chroot the user they can open /data/somefile and it will work.
As for file space is concerned, I can setup a chroot_usr directory that I hard
link to the users home directory as usr. So when they reference /usr/bin/perl it will
work (and I won't need a bunch of copies of perl).
Now, my question is this; how much overhead were you talking about for the chrooted
system calls? I was under the assumption that it just took up more memory (to
exec another shell).
- Chuck
btw, sbox wasn't in freshmeat, but I did find it at
http://stein.cshl.org/~lstein/sbox/ (for those reading the thread).
On Mon, Dec 02, 2002 at 06:58:55PM +0100, Davide Giunchi wrote:
>
> This is what i was searching before using apache in a real-world mass
> VirtualHosting system.
> The direct answer to your question is: sbox, you can search for it on
> freshmeat.net .
> I've used it, but to permit a little scripting to the users via a chrooted env
> you must compile a little chrooted env that use ~ 20Mb for each VirtualHost
> (libc6, bash, perl with some modules), so you will loose a lot of space.
> And then for php? woudn't you like to chroot php too? so you will need to
> compile php too, so other space is needed, minimum other 10Mb.
> Second sbox is a program of 1997, no other's upgrade since now, it works but
> do you trust it for the future? i will use it only if i've a good C and
> suexec.c internal knowledge.
> Last but not least every cgi-bin (or php) will need a chroot system call(),
> and this is not a little ovevrhead on a big system.
>
> So after little test i've found that i can grant a big security running wole
> apache on a chroot, protect every user's documentroot with unix permission
> and using suEXEC.
> In a chroot you can deny every users to look at /etc/passwd and other
> important files, and with simple permission you can permit to every user to
> look only at his document root and not other's users document, yes it can
> surf on the filesystem but with a chroot you have little files so you can
> control it quickly with unix permission.
>
> Regards.
>
> --
> Davide Giunchi.
> Membro del FoLUG (Forl? Linux User Group) - http://folug.linux.it
> GPG Key available on http://www.keyserver.net
> Fingerprint: 4BFF 2682 6A58 ECFE 071B A1A4 F2A3 9EFA 6494 81FD
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org