More restricted execution silly ideas

[Shawn Pearce]

I think this is kind of the direction I had been suggesting earlier.

I thought about it more last night.  If it was possible to read a
.beam file in Erlang, perhaps we could do something like this:

	- Designate a directory path as "trusted" to the code server.
		- Any path not desginated is assumed untrusted.
	- Within a "trusted" directory path desginate a set of "safe"
	  modules.  All others are "restricted".

When a module is loaded, if it comes from a "trusted" directory,
the code server loads it as is.

If the module is from an untrusted directory, the code server
rips apart the .beam file and begins to "verify" it:

	- Remove all native HiPE code.

	- Any simple call (e.g. code was:  lists:length(X)) where module
	  and function were statically known at compile time:
		- Load module lists now (if not loaded).
		- Check type of directory it came from:
			- Trusted:
				- If a "safe" module, leave call alone.
				- If not "safe", module call must be 'fixed':
					rewrite call to be:
						SM = get(security_manager),
						SM:apply3(lists, length, [Arg])
			- Untrusted:
				- Leave alone.

	- Any non-simple function call (those we can't determine either
	  function or module name now, or that uses apply/3):
		- Rewrite call to be:
			SM = get(security_manager),
			SM:apply3(lists, length, [Arg])
	  
	
	- Any message send instruction:
		SM = get(security_manager),
		SM:send_message(To, Data)


	- Any unsafe BIF/erlang module calls: (put, spawn, open_port, etc.)
		SM = get(security_manager),
		SM:erlang_bif(BifName, [Arg])


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.

I thought I might dig around this weekend and see if I can find some
of the old messages where the .beam file was discussed to see how
practical this would really be.


erlang@REDACTED wrote:
> I had another thought on implementing a restricted execution environment for
> untrusted erlang code:
> 
> How about, instead of trying to lock down an erlang virtual machine, instead
> putting the erlang code presented through a cleanser which pulls out any
> functions which are regarded as unsafe?
> 
> Code which doesn't refer to anything unwanted passes through and is executed
> without a murmur.  The rest is hacked up, probably won't even compile, and
> is left to bleed, or returned without running?
> 
> Or simply specify a limited set of functionality, and inspect incoming code
> for violations?
> 
> I suspect this might be easier than hacking up OTP and erlang.

-- 
Shawn.

  You can't have your cake and let your neighbor eat it too.
  		-- Ayn Rand