bytecodealliance / lucet

Lucet, the Sandboxing WebAssembly Compiler.
Apache License 2.0
4.07k stars 164 forks source link

Provide example of CPU-limited sandboxing of lucet programs #192

Open bouk opened 5 years ago

bouk commented 5 years ago

I'm interested in using Lucet for a project, but I have security concerns with running user-provided code (of course). I think it would be very useful if you could provide a description of the sandboxing method you use for Terrarium, or even provide some example code that shows how you're sandboxing the user code so it can't consume the whole CPU.

jedisct1 commented 5 years ago

Hi Bouke,

Unfortunately, this is not possible yet, at least not in a simple and safe way, but this is something being worked on.

In Terrarium, there is only a global timeout, enforced on the whole container.

pchickey commented 5 years ago

We also think it is important to support CPU-limited sandboxing :) @tyler is working on #150 and we've got some napkin-sketch design ideas about how to instrument the generated code to enforce more granular timeouts. At the moment we're a bit stretched for resources and may not be able to solve this within the next few months, but if this is something you'd like to work on with us, we'd love to collaborate!

bouk commented 5 years ago

I see, good to hear it's on your radar! I have some vague ideas about projects I would like to use lucet for, but not really the time to contribute major features, sorry :smile:

Semi-related question: do you think lucet will be able to provide enough protection and limiting to be able to safely run user-provided programs next to each other in the same process, outside of another sandbox? Or will some kind of cgroups/seccomp sandbox around lucet always be required?

pchickey commented 5 years ago

Lucet should be able to protect against some classes of attacks from using user-provided programs in that scenario, if the embedding correctly separates the two programs and does not permit them access to some shared resource through imported function. This is one of the goals of lucet-wasi, for instance - if each module is given their own subdirectory to read/write into the filesystem, they shouldn't be able to interfere with each other.

There's a pretty comprehensive rundown of what Lucet does and does not protect against here: https://github.com/fastly/lucet/blob/master/SECURITY.md but if you have any questions we are happy to answer them.

maxmcd commented 4 years ago

user-provided programs next to each other in the same process

shouldn't be able to interfere with each other

I assumed that even with speculative execution protection (eventually) implemented in cranelift that the general consensus was that isolating untrusted code within the same process was very challenging: https://v8.dev/blog/spectre#site-isolation

I am also working on a project with Lucet and have assumed that it's best to have a separate process for each user. It would be interesting to hear if in Fastly's efforts with Lucet it is planned to run multiple user's code in a single process, or if the best bet at this point is to split them up.