I just went through the Java Document quickly, and came up with these notes.
The document is pretty old, so I'll go over the security section in my Java2
book over the weekend. Some of these may actually change my original doc. I'll
update it as I get a chance. ('SecMgr' is short for Security Manager, which is
how Java defines it, not me).
--------------------------------------------------
watch that memory limits don't cause leaks (XSUB)
non-object namespace limits? pre-defined namespaces?
sockets (if core) and threads (if core) limiting
%ENV vars must be 'public-ized' for cgi
socket "read & run" access
socket "read & send" access
SecMgr must not be able to re-read .cf files while running
SecMgr must kill Perl before giving up the ship (no leaks)
Java checks to see what classes are involved in the security
request to see if they are 'trusted' to manage the resource:
"In the Snark example, the security manager examines the
execution stack and sees several classes, including Snark.
...if one of the classes currently on the execution stack is
part of an applet or some other untrusted, dynamically
loaded program, then granting the request could be
dangerous."
Perl could see if it's part of an eval statement(?).
Perl should allow for testing pro-actively so that a script
doesn't spend alot of time trying to do something that Perl
knows that it is not permitted to. (maybe during parse?)
Class dependencies should be taken into account for trusted
classes, but should not force the admin to 'allow' loading that
sub-class independently. (load only through the trusted class).
globs (symbol table access, anyway) denying. maybe pseudo-tables.
Module load locations (no modules from untrusted locations).
Checksums in .cf to identify trusted code. (automatically
generated by "perl -p cgi.cf"(?), reads and creates 'signatures')
Perhaps some sort of 'predefined' security models.
Any comments would be appreciated (on this or the original),
Grant M.
