Boa as a sandbox

[arendjr]

I noticed that Boa is separating ECMAScript functionality from runtime functionality, by putting the latter in a separate crate. This is great. Unless I'm overlooking something, this means JS scripts running inside Boa cannot perform any network or filesystem activity unless explicitly allowed through exposed runtime functions, right?

Does this also mean that it is safe to use Boa as a sandbox for JS scripts? I understand if you cannot make promises of this matter, but is it the intention of the project that scripts running without additional runtime functions should be always safe to run from the perspective of the host? It might be helpful if the documentation provides some kind of statement on your stance with regards to security.

It might also be good to clarify your regards the use of unsafe here. I found 92 instances of unsafe in your code (excluding tests and examples). At first glance, most are easy to verify as being safe, but I wonder what your policy is.

Thanks!

[jedel1043]

Will try to answer every question individually.

JS scripts running inside Boa cannot perform any network or filesystem activity unless explicitly allowed through exposed runtime functions, right?

Correct, and this is by design. The only host APIs that are always exposed to the engine are the allocator, the filesystem and stdio. Furthermore, we're also investigating ways to completely isolate the engine from std (see #2543).

Does this also mean that it is safe to use Boa as a sandbox for JS scripts?

Safe from a security standpoint? Yes. Any method that allows manipulating the host without passing through an exposed API is considered a bug from us. However, from an execution standpoint, the engine can still hang indefinitely or allocate too much memory and crash the main process, but we're actively working on ways to limit the execution space-time of an active context (#2350, #3442).

It might also be good to clarify your regards the use of unsafe here

We're a bit more pragmatic with our policy about unsafe; a well documented unsafe block/API is fine to us, mainly because we use it a lot for optimizations, API improvements and low level data structures. A recent example of an API improvement that wouldn't be possible without unsafe would be #3618, which depends a lot from NonNull pointer casts, but significantly improves the ergonomics of JsObject.

[arendjr]

Thanks a lot for your response!

The only host APIs that are always exposed to the engine are the allocator, the filesystem and stdio.

Just to clarify, when you say the filesystem is exposed to the engine, that doesn't mean the filesystem is exposed to scripts inside the engine, right? I suppose the engine needs fs access to import scripts from it? What if I use a custom module loader?

[jedel1043]

Yes, the filesystem is only exposed for the embedder. No JS APIs can access the filesystem without exposing a native function first.

[jedel1043]

I suppose the engine needs fs access to import scripts from it? What if I use a custom module loader?

Yeah, those are the only APIs that use the fs. If you only parse scripts from strings instead of files and you implement a custom module loader that cannot access the fs, you would essentially isolate the engine from the host filesystem.

[arendjr]

Perfect!