Skip to content

Dynamic capabilities / pre-opened filesΒ #66

Open
@MarkMcCaskey

Description

@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).

Metadata

Metadata

Assignees

No one assigned

    Labels

    capabilitiesIssues related to the wasi capabilities system

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions