Provide example of CPU-limited sandboxing of lucet programs

[bouk]

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]

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]

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]

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]

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]

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.