Dynamic capabilities / pre-opened files

[MarkMcCaskey]

A major problem we're seeing with using WASI, in contrast with Emscripten and unsandboxed code, for human-in-the-loop uses of WebAssembly is: how does the user know which capabilities a module will need?

Currently the flow is:

1. User runs WebAssembly module. Module does computation. Module encounters missing capability (preopened file descriptor).
2. Optional step: module causes intermediate state changes and can't run correctly anymore
3. Module terminates with error
4. User adds capability
5. Optional step: User reverse engineers what the module was doing and cleans up after it
6. Repeat steps 1-5 until module works

What we need is a way for the WASI module to ask for more permissions. We've considered adding something like this for WASI as it is now, but I think having it in the WASI standard is the way to go. And in the case of preopened file descriptors, a WASI-native solution will be much nicer than having the host edit the libpreopen data structures in WASI memory.

Alternative solutions:

• Drop the sandbox, grant all permissions by default. Here for completeness -- I think we don't need to discuss this.
• Set things up such that all capabilities can be statically inferred. Even if this were possible (and I don't think it is), having all possible permissions a module might need either on or off seems like a sub-optimal outcome.
• Have WASI modules declare/request their required permissions ahead of time. Very similar to the above with the same draw-backs.
• Have individual runtimes solve this problem independently. Not an unreasonable solution, but will increase fragmentation and the barrier to entry.

Known issues

• Existing code may, for example, look at a bunch of file paths to infer things about the system and having them fail rather than alert the user may be the best thing to do.
• Blocking on requesting permissions in situations where there is no one to grant permissions. We'd have to support both uses.
• Cognitive load on the user: in the case of multiple modules of various levels of trust, presenting the requests in a clear way to the user could be difficult. Having only the top level module able to request permissions and then sub-dividing them from there could help.
• The granularity of preopened directories is very large. If I'm running a CLI tool and I give it a file as a command line argument, I'd expect it to only access that file and maybe its own internal data files, not .ssh if I happen to run it in my home directory.[1]

I think this was mentioned in passing in one of the previous meetings, but I'd like to restart the conversation around this. Getting this right is critical to having WASI and sandboxed/secure computation used for user-facing applications.

Please share your ideas about this, suggestions for alternatives/known issues, and intermediate solutions that you all have been using if you've encountered this issue!

[1]: We've considered special casing uses like this (inferring permissions based on command line arguments) because we solved the "program relies on a pile of files to work correctly" problem for our uses with wapm package filesystems (statically declaring host file dependencies outside the WASI module). This is a band-aid though and is easily defeated, like in the case of a compiler which not only reads the file you gave it as an argument and its pile of files, it needs to output file(s).

[devsnek]

Perhaps a duplicate of https://github.com/WebAssembly/WASI/issues/5?

[MarkMcCaskey]

Perhaps a duplicate of #5?

Good call! I didn't see that when posting this now, but unfortunately I'm not able to comment on that issue.

You can't perform this action at this time.

So opening a new issue seems to be my only way of contributing in any case.

[piranna]

Deno use capabilities and ask for them when needed. Could be investigated for inspiration. I think we could diferenciate between mandatory required capabilities that the application needs to work, and optional ones only needed for some features.

[devsnek]

@MarkMcCaskey odd... you should be able to comment on it, perhaps github had a hiccup.

@piranna the general design goal (as said in 5) is that wasi uses these manifests to pre-request resources. Beyond that, applications could add additional ways to get capabilities (like deno's, where it pauses and confirms with the user). I don't think it would make sense to enforce that runtimes need anything more than support for the manifest though.

[piranna]

I don't think it would make sense to enforce that runtimes need anything more than support for the manifest though.

Fair enought. Yeah, maybe would be a good idea to left that permissions to each runtime, that doesn't goes against the fact the manifest show what capabilities are mandatory so the app/library can work, and what ones are optional and left to the user to enable them or not.