More restricted execution silly ideas

[erlang@REDACTED]

> I think this is kind of the direction I had been suggesting earlier.
[snip bit about defining trusted module directory] 
> When a module is loaded, if it comes from a "trusted" directory,
> the code server loads it as is.

How about if we just allow OTP contents, and then cherrypick from those
which actual calls we will permit?
 
> If the module is from an untrusted directory, the code server
> rips apart the .beam file and begins to "verify" it:
[snip approval algorithm] 
> Basically we allow 'system' code to run without penalty, and allow user
> 'unsafe' code to run with minimal penalty, basically anytime they want
> to access external resources.  Basic calls to stdlib such as lists,
> sets, dict are all allowed as-is.  Its ets, file, code, message sending,
> modifying the process dictionary, etc that are slower.  By putting all
> calls through a security_manager module, the security_manager can
> decide how a call should react, and can either emulate the real call,
> or check access (based on arguments, etc) and forward or exit/1 as
> necessary.

This seems a bit overhead-rich.  The idea (to me, at least) is that if
one can simply define a standard subset of standard functions which can
be permitted (typically, aside from message passing and spawn/3, anything
which has particular side-effects with reference to machine state), then
this subset can be permitted without any interference at runtime, which is
good for things like realtime behaviour.  Ultimately, the execution becomes
more functional, in the sense of isolation from side effects, until the 
program hands back the answers in the form of messages.

In addition, I'm unsure why analysis of .beam files would be really preferable
to analysis of .erl files ...

If one were to simply slurp through standard erlang/OTP source code, and 
ruthlessly mutilate anything with outside references beyond, say, messages,
then one could pretty much guarantee that what happens inside the virtual
machine is the concern of that program and its spawn only (load on available
resources notwithstanding).