[lug] preventing malicious scripts

[D. Stimits]

charles at lunarmedia.net wrote:
> 
> is there a method to set a directory as a able to execute cgi scripts,
> however limit which scripts within the directory are executable?
> 
> i thought about the possibility of limiting it based on name, however i
> would assume the crafty client would simply upload a malicious script with
> the name of the accepted script and still be able to gather the info i am
> trying to prevent them from retrieving.
> 
> any ideas on how to let clients have access but still be able to sleep at
> night?
> 
> thanks -charles
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug

You can create a chroot environment. What chroot does is that the
particular application sees the chroot point as the new root directory,
and nothing to its parent is visible. But that also means any support
needed to run must be duplicated in the chroot environment. Even if that
entire environment is destroyed, nothing outside can be seen. For
example, if I have a statically linked executable, with no outside
requirements except maybe /lib, /bin, and parts of /usr/bin, you could
do this:
create /usr/local/sandbox
create /usr/local/sandbox/bin (give it a copy of /bin)
create /usr/local/sandbox/usr/bin (give it a copy of /usr/bin,
selectively copying only what is needed)

Then in your application, have it chroot /usr/local/sandbox
Your application can no longer see anything that is a parent to
/usr/local/sandbox, and in fact thinks /usr/local/sandbox is actually
"/". If you fail to provide any resource needed for the application to
run, it will fail. I haven't tried this for cgi, but you could
conceivably put your entire web system in chroot so it is independent of
the rest of the system. Once it goes chroot, it won't come back till you
reboot.

The only time I've actually used chroot is that I have booted from a
rescue CD, then did a chroot to the root partition of the real install,
which was mounted somewhere like /mnt/rescue, and I'd run chroot
/mnt/rescue. I'm then running from the rescue kernel, but everything
will now be in relation to my regular hard drive install instead of the
CD. Running lilo will do the proper thing at that point, and instead of
looking for /etc/lilo.conf from the CD, it'll see
/mnt/rescue/etc/lilo.conf. You could conceivably run from a rescue
floppy and chroot, then have your full install available. From a
security standpoint, you can do the reverse, and take a full install,
and cause a shell or other program chroot to a smaller, contained
environment. Check out "man -a chroot", it'll give both the command line
version, and the C API call to do it. If you want to get an estimate of
what is required to run a particular program, use ldd and search out the
libraries it wants. If you run something like a bash script or a perl
script, then you have to instead find out what bash or perl want, ldd
won't work on a script.

D. Stimits, stimits at idcomm.com