Sandboxing a Rust/wasm32/JS app

1

I'm looking for a way via Deno, Chrome, Tauri, Electron, or whateverelse that allows me to sandbox a Rust/wasm32/JS app.

Context: I have a Rust/wasm32 that runs in Chrome. This app does two things:

  1. sends shell commands to a local Rust/http server (it basically has shell access to the local system)
  2. this Rust/wasm32 app also pulls in packages via npm (during build process); example CodeMirror / Monaco, with plugins

The interaction of #1 and #2 makes me very uncomfortable. What if #2, at runtime, for some stupid log / diagonistic / statistics, pulls remote JS and executes it? Well that remote JS, now, through #1, has shell access to my local system.

Now, I am trying to figure out a way to say: "this container can ONLY talk to localhost:8080".

==

XY problem: I'm trying to build a mini-IDE/editor/shell ; using Rust/wasm32/JS for the frontend, but dealing with untrusted JS is making me very very uncomfortable, unless I can control the network of the "app container".

Thanks!

2

If your application “is a shell” — that is, it allows the user to specify arbitrary commands — then you have to rely on all the JavaScript (and Rust) that you're including not being malicious-or-foolish, unless it is running in a sandboxed-iframe or something and is not on the path between the user's input and executing commands. This is not a technical limitation[1] so much as a logical necessity: anything that can edit the UI can make it look to the rest of your program like the user typed something they didn't.

If I were in your position, I'd be working on auditing my dependencies and keeping them few.

  1. though technical choices can reduce the amount of code that creates this risk, and require multiple conspirators instead of one source ↩︎

3

I see, is your argument I'm looking at this at the wrong layer:

  1. if I trust the imported npm, I have no need for this
  2. if I don't trust the imported js, even if I limit it to localhost:8080, even if it does not load remote js, it can still cause problems

?

4

Yes.

I'm not saying that you shouldn't take steps to sandbox components where that is feasible; only that, for this sort of critical application, you also want each component to be as known to you to be trustworthy as you can manage. Anything that is “untrusted JS” needs to not even be included in your dependencies.

But sandboxing or any reduction in available permissions is still useful to minimize damage from bugs or attacks, even when it doesn't provide any absolute guarantees.

Getting back to “this container can ONLY talk to localhost:8080” — you can likely implement this via Content Security Policy (CSP) - HTTP | MDN which can restrict which domains are contacted, and also turn off script evaluation. Electron/Tauri might have their own more specialized configuration too (I don't know, as I haven't used either).

1 Like
5

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.