Dear Perlmonks:
My linux apache web server was recently hacked, so I have become more security conscious. Amazing what a little hack will do to one...
I was thinking that it would be a good idea to jail each perl cgi program that I am running to the file system hierarchy that it needs to read/write into. my perl cgi program would first load all the necessary external modules, then do a
Even if my perl script later does something truly stupid and a web user can gain control of my perl cgi program, the damage will be limited to stuff in /var/www/user1/. Because apache runs cgi and fcgi program not as root, breaking out of such a jail will be difficult.chroot("/var/www/user1/"); chdir("/");
alas, this has the obvious issue that the chroot() call itself requires super user privileges. I am a little confused by this--why is this security restriction there to begin with? before the chroot, I already have access to everything that I have access to after the chroot. I am whittling down what I can do, not expanding it.
can I make a non-setuid program capable of executing the chroot() call? I also tried
does not work even if I setuid /usr/sbin/chroot, because the system call wants access to "/bin/bash". I am not sure why---I thought this version would exec the chroot directly.system("/usr/sbin/chroot","/var/www/user1")
I would think it would be a bad idea to change my perl cgi scripts themselves to be setuid root, so that I can chroot from inside perl. I know I can drop the setuid privileges later, but the whole idea is to protect myself from stupidity afterwards. giving my cgi programs root privileges is something I would rather avoid.
advice appreciated.
/iaw
In reply to chroot() security in cgi script? by iaw4
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |