Having written a lot of insecure programs in the past, I see
your problem in a somewhat different way.
You may be running sh, awk, sed, cat echo, rm, cp, etc, etc on
firewall machine. If those tools are insufficient or inadequate,
then the question is what functions are lacking from those well
audited and proved to work tools. Of course these tools can be
used in insecure ways, having perl or C programs means going off
beyond those 'established' functionalities. This in turn means,
other than giving crackers their convenience, you might have
additional burden to audit those brand new programs.
On the other hand, if the firewall could be more secure with only
these new programs, then you might have to choose installing perl.
Even then, you would not need full standard set of perl.
BTW, the only functionality I missed while writing auditing tools
myself in standard commands was flock, which I could substitute
with filelock from procmail. But YMMV.
horio shoichi
"Kempter, Lynda L." wrote:
>
> To perl, or not to perl; that is the question. Literally.
>
> A request has been made to install perl on the firewall. (It
> would run some system audit routines, bring it in line with the
> rest of the internal unix systems.) Given the choice, I'd rather
> not. Why give the hackers yet another tool to use when they
> break into the firewall? I wouldn't put a C compiler on the system
> for the same reason. The argument for installing perl is that it's
> much more "secure" than something like C, and no more insecure
> than shell scripts.
>
> I'd be most grateful for opinions, pro and con, from the list.
>
> Cheers,
> Lyn
>
> <*> [EMAIL PROTECTED]
> "Expect me when you see me."
>
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
