4 ms·

Does this mean we'll also have a mechanism like pledge(2) to assert that the root nanoprocess or any privileged brokers only needs access to certain APIs, and p

• JoshTriplett 7y ago
  The WASI and Bytecode Alliance approach is based on capability-based security, granting only the access needed for a module to do its job.
  • tschneidereit 7y ago
    To expand on this, capabilities allow us to go further than pledge(2): it enables selective forwarding of capabilities to other nanoprocesses, such as only forwarding a handle to a single file out of a directory, or a read-only handle from a read-write one, etc...
    • jedisct1 7y ago
      Capabilities are also more complicated. I fear that at the end of the day, capabilities will have the same fate as other sandboxing mechanisms: nobody will use them. And, just so that their application works and avoid support burden, developers will tell people to use a setup that enables access to everything. pledge(2) and unveil(2) learned from the past and are way simpler. I really wish WebAssembly had adopted similar mechanisms.
      • tschneidereit 7y ago
        Agreed, and there are a lot of UX questions to sort out. Many security concepts took many attempts to figure out in full (or to the extent that they have been figured out :)) One important aspect here is that this doesn't just target whole apps. It also targets developers using dependencies: while it's desirable to restrict an application's capabilities, there's a lot of value in developers only giving packages they depend on very limited sets of capabilities. And that seems much more tractable, given that kitchen-sink packages aren't what most people want to use anyway.