David Garamond wrote:
> i've been playing with Safe.pm for the past two days, and it's really
> giving me headaches :-) i can't seem to do anything really useful with
> it. the namespace "chroot"-ing makes me unable to use pretty much every
> extension modules i want to use. dynamic loading also doesn't seem to
> work at all inside the safe compartment.
>
> so i set back and rethink what actually i want to accomplish in the
> first place. that is: i want to prevent an untrusted and potentially
> dangerous perl code from doing these things:
>
> - accessing certain part of filesystems;
> - using sockets to communicate with the outside world;
> - access databases;
> - write or read shared memory;
> - executing other programs;
>
> in essence, i want to prevent the snippets of perl code that i will be
> receiving from the Net to store information persistently and/or send
> information outside ("phoning home", etc). i'm not really concerned
> about resource limiting at the moment; i can always kill the naughty
> process or let my OS do that.
>
> looking at the examples David and Steve Grazzini gave a couple of days
> ago, i thought that perhaps overriding builtin functions will
> sufficiently do that. that is, if i do this:
>
> #!/usr/bin/perl
> BEGIN {
> sub CORE::GLOBAL::system { die }
> sub CORE::GLOBAL::exec { die }
> sub CORE::GLOBAL::open { die }
> sub CORE::GLOBAL::sysopen { die }
> sub CORE::GLOBAL::socket { die }
> sub CORE::GLOBAL::require { ... }
> # ... and a bunch of other functions ...
> }
i am afraid that your approach is not going to work well. it's not just the
Perl functions that you need to mask out, Perl has a bunch of operators
that can be used to talk to the outside world. just to name a few:
print qx/ls -l/;
`ls -l`;
...etc. they can replace anything they want for 'ls -l'. i can't remember if
those can be overloaded or not. to be honest, this kind of thing is
*really* tricky.
david
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
