go ahead... be a heretic | |
PerlMonks |
chroot() security in cgi script?by iaw4 (Monk) |
on Jan 03, 2012 at 18:32 UTC ( [id://946109]=perlquestion: print w/replies, xml ) | Need Help?? |
iaw4 has asked for the wisdom of the Perl Monks concerning the following question: 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. 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. 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
Back to
Seekers of Perl Wisdom
|
|