(Update: I spotted a hidden but reasonable assumption that deployment takes place in chain from some other environment where compilers and interpreters are freely allowed).
But it is worth pointing out that for these purposes, the perl executable is not a compiler but a scripting interpreter. Assuming there is no webserver running, if it were me, I'd demand that they be consistent about it, i.e. remove /bin/ksh and /bin/sh (the erm "predecessors" of Perl :)) or they allow /usr/bin/perl - there is then zero difference from a security point of view between one scripting language and another. Of course, they can't remove ksh and sh because that would break the system so badly it would descend into a coma never to return or reboot, requiring reinstallation of the operating system.
If the system is indeed connected to the internet, a more reasonable and far more competent security precaution would be nevertheless to restrict the execute permission of /usr/bin/perl to 750, chown it to the group where applications run and to run the webserver in a separate group.
The real incompetence is usually running webservers as root and it is ridiculous to blame Perl for the security consequences of that - i.e. it is like rearranging the deckchairs on the Titanic.
-M
Free your mind
In reply to Re: Secure deployment of binary perl modules
by Moron
in thread Secure deployment of binary perl modules
by KillerDll
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |