[4873] in WWW Security List Archive
Re: user cgi advice
daemon@ATHENA.MIT.EDU (Richard Costine)
Sat Mar 22 00:23:17 1997
Date: Fri, 21 Mar 1997 22:57:49 -0400
From: Richard Costine <rjc@n2k.com>
To: elroy <elroy@kcsun3.kcstar.com>
CC: www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
elroy wrote:
>
> Hello all -
>
> I've finally had a client write their own cgi, and they'd like to
> install it for their web-site, which I host on a machine with 56
> other domains.
>
> Up until this point we've developed ALL cgi on any of our sites.
>
> I'm concerned about the impact his programming could have on the
> machine, and on the other sites. His business isn't worth losing one
> or more other domains when his screwed-up or poorly written programs
> run amok.
>
> The environment is interesting - I've created chroot'ed environments
> for all users who require shell/ftp access, and the httpd's for each
> domain run under their own unique (for each site) uid, which helps
> segregate permissions and access. The httpd's run from the server
> level however, NOT within the chroot'ed space.
>
> My initial thought is to tell them yes, as long as we review the code
> and install everything from source. We'd be charging the per hour
> programming fee to review the code, by the way. However, we still
> haven't filled an open programming position, and we're shorthanded
> and falling behind on our projects, so I'm not thrilled about being
> distracted by someone else's code.
>
> I'm really in a quandary, and hope someone else has found a good
> solution for user cgi's. I'd be happiest if I could be secure AND
> give the client freedom to program.
>
> I've been thinking setting pretty low ulimits on their processes
> might help, but I'm generally drawing a blank. Maybe if I implemented
> a hefty fee for restoring files from backup, too... : )
>
> If anyone has any good advice for me, PLEASE let me know,
> either on this list or via personal e-mail. I really appreciate it.
>
> Thanks in advance -
>
> -elroy (elroy@kcstar.com)
We run most of our webservers chrooted...
(ie. chroot /home/jail /home/www/apache/httpd ...)
It makes it really tough for someone to crack the box - but not
impossible. The Webserver runs as a non-root user.
If you're really paranoid - set up a separate chrooted webserver on a
separate physical machine. Give the users their own playpen that they
can destroy. Pentia and ethernet hubs (10BaseT) are cheap. Freebsd and
Apache are cheaper. You could isolate them off on their own LAN behind a
filtering router or proxy gateway (ie. firewall). That way packets from
their box won't make it to your network easily.
What you're really saying is that you don't trust them - that means you
need to isolate and filter them from your own work.
PS. you should always back up the entire machine first, and periodically
backup the user's work somewhere. That way if you suspect a breakin,
reinstall the OS from that initial backup and overlay the users document
root from your last backup.
Remember filter where possible, and isolate when you can't filter.
Good luck.
