Safe module security and emebeded perl

[gildir]

Fellow monks,

I want to use module Safe to restrict emebeded perl code to only 'reasonable' set of operations. This emebeded code is a part of XML templating system that was private, but now I want to give users a chance to modify their templates. But as the whole system runs in mod_perl with persistent DB connections, I do not want users to be able to access that DB connection or any other resources on server system.

I here the question: What opcodes could be reasonable to permit in such a circumstances? Just now I have qw(:base_core :base_mem :base_loop print sprintf refgen padany gv) set, but I'm not sure especialy with 'padany' and 'gv' opcodes. I had to include them to allow things like my $foo; and use of $_ in templates. Is there any security risk when permiting them?

print operation is used for generating output, so it is needed. I have selected tied filehandle that collects output. That should be OK as far as I do not overlook something.

refgen is also needed, because I pre-compile templates with

my $code = $compartment->reval("sub { ".$templateCode." }");

and then runs it (outside compartment) with &$code. Is there some security risk in this setup?

Thanks for any help or comments.

[tye]

I'll preface my remarks by noting that I'm not an expert on Safe.pm nor mod_perl, so don't be too surprised if I'm mistaken on some points.

If you store anything in global variables (such as a database module that stores the database connection in a package global), then those can be accessed under such a scheme. Since you are using mod_perl, this becomes rather likely as file-scoped lexicals don't play well with mod_perl and that leads to using package globals.

I wonder if this setup prevents the use of things like Win32::TieRegistry and Win32API::File which would let your users do all sorts of system damage if on Win32 but that don't use things like open that Safe.pm would know to lock up. There may be other similar modules such that non-Win32 system would be similarly vulnerable.

I also suggest you search for information on the current state of the art of Safe.pm. I vaguely recall people finding ways around its protections.

        - tye (but my friends call me "Tye")