Comment by otterley

Comment by otterley 15 hours ago

6 replies

Note that "sandboxing" in this case is strictly runtime sandboxing - it's basically like having a separate process per event loop (as if you ran separate Node processes). It does not sandbox the machine context in which it runs (i.e. it's not VM-level containment).

Brass_Hopper 14 hours ago

When you say runtime sandboxing, are you referring to JavaScript agents? I haven't worked all that much with JavaScript execution environments outside of the browser so I'm not sure about what sandboxing mechanics are available.

  • otterley 14 hours ago

    https://nodejs.org/api/vm.html

    Bun claims this feature is for running untrusted code (https://bun.com/reference/node/vm), while Node says "The node:vm module is not a security mechanism. Do not use it to run untrusted code." I'm not sure whom to believe.

    • Brass_Hopper 13 hours ago

      It's interesting to see the difference in how both treat the module. It feels similar to a realm which makes me lean by default to not trusting it for untrusted code execution.

      It looks like Bun also supports Shadow Realms which from my understanding was more intended for sandboxing (although I have no idea how resources are shared between a host environment and Shadow Realms, and how that might potentially differ from the node VM module).

    • Jarred 14 hours ago

      The reference docs are auto generated from node’s TypeScript types. node:vm is better than using the same global object to run untrusted code, but it’s not really a sandbox

    • sheepscreek 13 hours ago

      Doesn’t Bun use JavaScriptCore though? Perhaps their emulation, rather implementation, leans more towards security.

Muromec 14 hours ago

Running it in a chroot or a scoped down namespace is all your need most of the time anyways.