At 11:59 AM 2/23/2001 -0500, wiz wrote:
This is a start, which is very good, but I'm pretty sure that this is
taking things from the wrong angle to some extent.
In general, if everyone's mostly familiar with just Unix's security model
I'd really, *really* urge you to read up on other models. The link to the
VMS security manual's not a bad first step. Unix's security and resource
limiting model is really very primitive by modern standards. (Though the
inclusion of POSIX ACLs is a step in the right direction)
> o Scripts are only executable if listed in 'perl.cf'
> o Web/CGI scripts are listed in 'cgi.cf'
> o Allowable modules listed in perl.cf and cgi.cf
While perl's definitely a popular language for CGI coding, I think we'd be
better off with something rather more general than this. Perhaps a default
generally used with a way for embedding programs to change it at activation
or compile time.
Also, a yes/no is awfully coarse. Better to associate identifiers that
grant access to particular resources with programs listed in those files.
> o Ability to limit CPU, memory, disk
> (and nice?) (conditionally?)
Unfortunately these are all really platform-specific, not that having
them's a bad thing. There's also the issue of granularity--where do we
check for exceeding resource limits? To be meaningful it has to be at the
sub-opcode level (to some extent) otherwise badly formed regexes won't get
caught by the CPU limit.
> o Ability to restrict command line flags
> o Other specific conditionals(?):
> o Execute if $ENV{REMOTE_USER}/$user is defined/valid
Trusting the environment on Unix systems for security matters is a foolish
thing. On systems where part of the environment is protected (so only users
with system or group privileges can modify them) it makes more sense if we
can verify the security of the individual elements of the environment.
> o no spawns or conditional
> o no system or conditional
> o no evals or conditional
Generally speaking we ought to have the capability to use or not use any of
the opcodes. (Though locking out the take_reference opcode might be
considered rather extreme...)
> o filename write filtering (no .cgi, .pl, .sh, .tcl, ...)
> o filename read access (/etc, /var, maybe use regex)
These are reasonably crockable, and I'm not sure that perl can uncrock them
reliably.
> o IP lockouts
> o IP limits
> o Content-length limits (?)
These are webserver specific, and are better dealt with by the webserver
rather than perl.
> o always strict or conditional
> o DBI specific (conditional) (maybe this is overkill)
Definitely. These (which I snipped) are all things the DB's security model
should handle. If your DB doesn't have a security model you have bigger issues.
> o Other
> o mirrored passwd files (htaccess) (is this suid?)
> o perhaps a config file with no-no functions?
> o perhaps custom rules directives written in perl?
> o perhaps a .ini-style file with sections of rules.
This all seems CGI/webserver specific, and would be better handled there.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
