>>>>> "Matthew" == Matthew Byng-Maddick <[EMAIL PROTECTED]> writes:
>> I guess what I'm saying is, sure, you can't stop a native
>> function (which was called from parrot code) from doing
>> whatever it wants, but you can still prevent the parrot code
>> from using that function in the first place (right?).
> Yes, but looking at the current Perl core, a large number of the
> day-to-day useful modules are written native (read: in C), so
> you end up losing there. That's not to say that future ones will
> have to be, but... In reality, however, the problem as I see it
> is that this is a capability which, once acquired overrides all
> others (wheras the others can be mutually orthogonal).
Obviously this is a problem; however, this is one of the easier things
to solve in a system like Parrot. By constructing proxies to the native
libraries that allow the insertion of checks and restrictions, untrusted
code can be written to use the usual APIs without allowing them to
assume the full power of the usual implementations. So, presumably,
in the restricted environment, File would be replaced with
RestrictedFile which only allows accessing files in a certain
subdirectory, or owned by a particular user, or such; Socket would be
replaced with RestrictedSocket which can only connect to certain
hosts, or must prompt for permission to connect; and so on. One could
even imagine something like a RestrictedCanvas in a GUI application,
that allows the untrusted code to draw only on a small portion of the
application's window.
All this is very close to achievable in existing language; the *hard*
part is preventing DoS attacks on CPU and memory. Parrot should make
that doable as well, with the ability to run multiple interpreters in
the same process.
msg26694/pgp00000.pgp
Description: PGP signature
