[4919] in WWW Security List Archive
user cgi-advice SUMMARY
daemon@ATHENA.MIT.EDU (elroy)
Thu Mar 27 15:11:28 1997
Date: Thu, 27 Mar 1997 10:14:51 -0600 (CST)
From: elroy <elroy@kcsun3.kcstar.com>
To: www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
I had great response to my question of 2 weeks ago, and have summarized
the answers:
Answer #1 - Multiple servers
Have a separate server available to test code on. After it has been
proven, move the files to the production server, and change DNS for the
site to point to the new server.
- also -
Have a separate server available to run user-generated cgi on a permanent
basis.
Answer #2 - Run the httpd's under the owners uid
Create a separate document root and server directory for the user, and
run the daemons under their uid. Keep that uid from having rwx on ANY
other files in the main server document directories. This is suitable for
a server hosting multiple domain, each with their own namespace. This is
my situation - we don't have user web services, only domains.
- or -
Use cgiwrap - a tool to set-uid the cgi to the owner's uid upon
execution. This is a suitable solution for a server that has multiple
users under the main server document root. It has the disadvantage of
making the URL's look funny. Cgiwrap seems to be a favorite with ISP's
running user servers, BTW. I never even tried to use it, I just looked at
it - cgiwrap was recommended many times.
Answer #3 - Charge them an arm and a leg to review their code.
Speaks for itself - and I like it! :)
Answer #4 - Use code scanning tools
A product was mentioned from iss.net - I haven't checked it out. I'd have
to check it out before I could use it to check anything else out...
Seriously, I didn't even try it.
Answer #5 - Convince them your code is better
Pretty easy to do, what with root permissions and all. "Their code just
never seems to run right..." <---- EVIL ! ;>
My solution -
I created a chrooted environment for the user to log in with. They get
their own /usr, /etc, /bin, /sbin, /tmp and so on. They are unable to get
into the "real" filesystem of the server. I've limited their collection
of executables to the bare minimum needed to log in, and perl 5.003. I'm
also running quota on this user. I especially kept a compiler out of
their grasp. Makes me too paranoid.
I then created a server for this user's domain, runs under his uid, and
has a limited number of max procs. This server also uses the chroot
feature (it's a Netscape product), and is incapable of traversing into
the "real" filesystem.
Finally, I've set this user's ulimit way down, to prevent a job from
looping and hanging, and run a root cron job that stops and restarts his
servers every so often (scheduled with the ulimit in mind).
There you have it. I'm comfortably confident in this arrangement, but if
you see holes, please don't hesitate to tell me.
Again, thanks to everyone on this list for helping out a confused system
administrator, I couldn't have done it without all the great input from
the list-members.
-elroy (elroy@kcstar.com)
