The Bytecode Alliance: Building a secure, composable future for WebAssembly

Re:The Bytecode Alliance: Building a secure, composable futu... by tschneidereit on Tuesday November 12, 2019 @01:59PM (#21516962)

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

[ Parent | on HN ]

Re:The Bytecode Alliance: Building a secure, composable futu... by jedisct1 on Tuesday November 12, 2019 @05:29PM (#21518913)

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.

[ Parent | on HN ]

Re:The Bytecode Alliance: Building a secure, composable futu... by tschneidereit on Tuesday November 12, 2019 @05:48PM (#21519073)

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.

[ Parent | on HN ]