proj-oot-ootSandboxNotes1

http://lua-users.org/wiki/SandBoxes


http://stackoverflow.com/questions/4011260/sandbox-jvm-to-secure-server-from-untrusted-sources


http://lua-users.org/lists/lua-l/2011-02/msg01606.html

"

    Subject: Re: LuaJIT FFI __gc metamethod?
    From: Mike Pall
    Date: Mon, 28 Feb 2011 23:54:42 +0100

Josh Haberman wrote: > [...] but AFAIK Lua (without FFI) can be sufficiently sandboxed > such that a ptrace sandbox is not necessary.

Maybe for an extremly restricted subset of Lua and if you relentlessly scrutinize every single interface function you offer to the untrusted code.

Others have repeatedly failed to keep their sandboxes sealed. See Java, see Flash, see Acrobat. And they had 15 years of time to get it right. Why do you believe you can do better?

--Mike

"


security issue with untrusted subroutines and arbitary direct stack manipulation. Suggestion: the part of the stack visible to the metaprogramming constructs of any piece of code ends at module boundaries, unless the capability to look beyond that is explicitly passed in.

---

would like the ability to run instructions one at a time (for fair/'metered' execution during eg a chess ai competition), and to add arbitrary instrumentation in-between instructions (for eg profiling)

---

using race conditions in Go to effectively access pointers unsafely:

http://research.swtch.com/gorace

cmelbye 18 hours ago

link

Can you expand on why App Engine doesn't allow multithreaded Go programs? I never quite understood what they were trying to prevent you from doing.

reply

Animats 17 hours ago

link

Here's a description of the race condition exploit:

http://research.swtch.com/gorace

reply

andrewmwatson 20 hours ago

link

They most certainly do let you run Go on AppEngine?!

reply

cmelbye 18 hours ago

link

He didn't say Go. He said multi-threaded Go. GOMAXPROCS=1 on App Engine.

reply

---

not very useful for us (b/c it relies upon NaCl?) but mb worth a look:

http://blog.golang.org/playground

---

" To make this possible, we implemented allocation limits in GHC, which places a bound on the amount of memory a thread can allocate before it is terminated. Terminating a computation safely is a hard problem in general, but Haskell provides a safe way to abort a computation in the form of asynchronous exceptions. Asynchronous exceptions allow us to write most of most of our code ignoring the potential for summary termination and still have all the nice guarantees that we need in the event that the limit is hit, including safe releasing of resources, closing network connections, and so forth. " -- https://code.facebook.com/posts/745068642270222/fighting-spam-with-haskell/ (also discusses haxl)

---