🚀 go-pugleaf

In article <318709AF.2A95@daemon.apana.org.au>,
Frank C. <chopperb@daemon.apana.org.au> wrote:
>Dear Netizens,
>
>I am almost ready to launch my own home page which contains an 
>interactive Web spot requiring a Perl script. However my system 
>administrator will not accept Perl because of the alleged security 
>problems. My own research reveals that most interactive Web pages - 
>approximately 80% - use Perl scripts to execute them. Thus I require 
>advice on the following matters:
>
>1. What security hazard does Perl actually pose?
>
>2. How do I rectify the problem i.e. where can I get a suitable CGI 
>   script?
>
>3. Is there anybody out there who is prepared to assist me in putting
>   together a CGI-bin script for a fee? I live in Melbourne, Australia.

We have an environment here too where arbitrary user-written CGI
programs are unacceptable on our central system. That is precisely
why I wrote safecgiperl, built around the Safe extension module.
Extracting from the README:

   Thanks to an extension module for Perl which allows compartmentalised
   execution we can now ensure that user-written CGI programs written in
   Perl can be executed safely. Only a restricted set of the Perl language
   is available: uses of unsafe features (even within eval statements) are
   trapped and the program is not run.
   ...
   There are many Perl operators not available to the compartment in
   which your CGI program is run. These mostly include operators which
   provide access to the operating system. The following list is not
   exhaustive but includes the most common excluded operators:
   * system, `backticks`, exec, fork, syscall, signal handlers,
     pipes (including open(FOO, "|bar") and open(FOO, "bar|"))
   * network access (socket, bind, connect, ...)
   * File munging (rename, link, opendir, chown, ...)
   * System V IPC (shared memory, message queues, semaphores)
   * File tests (-r, -w, -l, ...)
   * Calling perl on other files (require, use, do 'file')

   Opening files for reading/writing is restricted. The "open" command
   is subject to the following restrictions:
   * Files opened for reading must be owned by the user.
   * Files opened for writing must be opened by using a filename containing
     no "/" characters. The filename is taken to live in the directory
     ~/cgi/out and the file must already exist at the time the open is
     performed. It can be a symbolic link if desired.

The current release is beta1 which was written for perl 5.001m.
A patch that comes with safegciperl-b1 fixes a couple of lines
for use with perl 5.002 (Safe now comes distributed as an official
part of perl and the error return API changed slightly from the beta).
There is a further fix that needs doing to get the open() wrapper
working with perl5.002: changing
     *{$cpt->varglob("open")} = sub {
to
     *{"$root\::open"} = sub {
in cgiperl. An irritating but harmless message to stderr can be worked
around by applying a patch to Safe.pm or waiting for the next release
(bug fixed by Tim Bunce, thanks). Because of all these minor nuisances,
I'm going to put together a proper 1.0 distribution of safecgiperl
shortly. You can get beta1 from
    ftp://ftp.ox.ac.uk/pub/perl/safecgiperl-b1.tar.gz

It's been running on our central Unix service for 7 months now and there
are a few thousand hits a day on user-written safeperl CGI programs.

--Malcolm

-- 
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Oxford University Computing Services
"Widget. It's got a widget. A lovely widget. A widget it has got." --Jack Dee