3 ms·

> That's because the way you're using secure is likely misleading to most people; two WASM programs will be more strongly isolated from one another than two nor

> That's because the way you're using secure is likely misleading to most people; two WASM programs will be more strongly isolated from one another than two normal programs This is wholly incorrect. Two WASM programs will be at most as isolated as two normal programs, but in practice substantially less so. Spectre being the obvious one that sort of "fully breaks" in-process sandboxing, but lack of hardware enforcement also means you're now more vulnerable to host bugs, too. Regardless it's a question of what is the juicier attack surface. WASM only cares about protecting the host from the embedded code, but it does that essentially by sacrificing the embedded code's own security from the outside world. That is, if A is the WASM host of B, and B can be called by C, then WASM is about protecting A from B at the cost of making B more vulnerable to C. If B is the thing that actually has the juicy data that C wants in the first place, this is a really bad tradeoff. If A is the juicy target, though, then this is a fine tradeoff. So in a browser context where the host is almost always the juicy target, WASM's tradeoffs work. If, however, you're talking about things like using WASM for web server sandboxing instead of docker or a VM, well the web server itself is likely the interesting attack surface rather than the "hypervisor." So that's probably not a good tradeoff to make there.

emn13 6y ago
The reason WASM programs are better protected from each other is because they have virtually no means of interop, and far fewer tricky CPU instructions available. Hypothetically, you might see classic OS programs use a sandbox that's as restrictive, but it's not common, and you'd have to compare each sandbox in detail to get an idea about the tradeoffs. By contrast, normal OS programs have all kinds of I/O, including inter-process communication, shared locks, high-res timers, shared memory, files, networking, etc etc etc. Even if those programs are "fairly isolated" by being inside a VM, they still have access to all kinds of low level tools that WASM won;t have that might leak enough entropy to still be less well isolated - and that's kind of necessary and by design, because a VM or container is designed to run largely unmodified binaries, and thus cannot simply omit capabilities legacy programs have - but WASM can, and does. Then there's simply the sheer complexity difference; it's pretty daunting task to have all that be entirely safe. In essence: there's a reason why it's much more common to see e.g. privilege escalation vulnerabilities than WASM sandbox escapes.
- kllrnohj 6y ago
  You're essentially arguing that WASM is a better selinux than selinux is. It isn't. WASM right now is missing all those things because WASM right now is a toy for moderately accelerating JavaScript. If WASM's usage expands beyond that, those feature limitations will rapidly vanish.
  - emn13 6y ago
    You're talking about some hypothetically fully featured WASM that has all kinds of attack surface it simply doesn't have today. It doesn't even have threads; nor accurate timers, nor shared memory; and those choices aren't by coincidence, they're by design to keep things safe (see e.g. https://github.com/WebAssembly/threads/issues/8 https://github.com/WebAssembly/threads/issues/8). If indeed webassembly adds features that add attack surface, I sure hope (and fully expect) them to take things like spectre into consideration. As to SELinux: the issue with securing existing programs is that those use all kinds of existing features; it's quite hard to take away functionality that programs depend on. SELinux simply has a much harder and trickier task than WASM, which never supported almost everything SELinux seeks to control in the first place. It may well be that it's possible to have SELinux enforce WASM-or-greater restrictions and that it would then be "safer" due to other features, but that's a pretty hypothetical scenario - what software would even run in those circumstances? The comparison seems moot to me; apples to oranges. One is trying to KISS and be safe by simply not having complex features; the other is trying to deal with real, existing programs by restricting stuff they could access but don't need. Those are different use cases.
    - kllrnohj 6y ago
      I explicitly stated I was talking about WASM being used in traditionally native process contexts - like in a serverless/microservices architecture. The first obvious step of someone offering that is to just import libc so existing code can migrate to it. You seem to be continually focusing exclusively on the current existing extremely limited WASM-in-a-browser usage. WASM's current limitations aren't intentional, it's because it's not finished & wasn't necessary for the MVP. In fact, it already has some of the things you are claiming it doesn't have - both threads & shared memory are available already in Chrome & Firefox's stable releases ( https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md https://github.com/WebAssembly/threads/blob/master/proposals... & https://webassembly.org/roadmap/ https://webassembly.org/roadmap/ ). Which means it also has accurate timers. WASM very intentionally allows the host to expose whatever feature set it wants. That's a very core design element. You can't just ignore that and focus on the ~nothing that the "spec" itself delivers & pretend that's by-design. WASM isn't a standalone runtime and isn't trying to be.

emn13 6y ago

The reason WASM programs are better protected from each other is because they have virtually no means of interop, and far fewer tricky CPU instructions available. Hypothetically, you might see classic OS programs use a sandbox that's as restrictive, but it's not common, and you'd have to compare each sandbox in detail to get an idea about the tradeoffs. By contrast, normal OS programs have all kinds of I/O, including inter-process communication, shared locks, high-res timers, shared memory, files, networking, etc etc etc. Even if those programs are "fairly isolated" by being inside a VM, they still have access to all kinds of low level tools that WASM won;t have that might leak enough entropy to still be less well isolated - and that's kind of necessary and by design, because a VM or container is designed to run largely unmodified binaries, and thus cannot simply omit capabilities legacy programs have - but WASM can, and does. Then there's simply the sheer complexity difference; it's pretty daunting task to have all that be entirely safe. In essence: there's a reason why it's much more common to see e.g. privilege escalation vulnerabilities than WASM sandbox escapes.

kllrnohj 6y ago
You're essentially arguing that WASM is a better selinux than selinux is. It isn't. WASM right now is missing all those things because WASM right now is a toy for moderately accelerating JavaScript. If WASM's usage expands beyond that, those feature limitations will rapidly vanish.
- emn13 6y ago
  You're talking about some hypothetically fully featured WASM that has all kinds of attack surface it simply doesn't have today. It doesn't even have threads; nor accurate timers, nor shared memory; and those choices aren't by coincidence, they're by design to keep things safe (see e.g. https://github.com/WebAssembly/threads/issues/8 https://github.com/WebAssembly/threads/issues/8). If indeed webassembly adds features that add attack surface, I sure hope (and fully expect) them to take things like spectre into consideration. As to SELinux: the issue with securing existing programs is that those use all kinds of existing features; it's quite hard to take away functionality that programs depend on. SELinux simply has a much harder and trickier task than WASM, which never supported almost everything SELinux seeks to control in the first place. It may well be that it's possible to have SELinux enforce WASM-or-greater restrictions and that it would then be "safer" due to other features, but that's a pretty hypothetical scenario - what software would even run in those circumstances? The comparison seems moot to me; apples to oranges. One is trying to KISS and be safe by simply not having complex features; the other is trying to deal with real, existing programs by restricting stuff they could access but don't need. Those are different use cases.
  - kllrnohj 6y ago
    I explicitly stated I was talking about WASM being used in traditionally native process contexts - like in a serverless/microservices architecture. The first obvious step of someone offering that is to just import libc so existing code can migrate to it. You seem to be continually focusing exclusively on the current existing extremely limited WASM-in-a-browser usage. WASM's current limitations aren't intentional, it's because it's not finished & wasn't necessary for the MVP. In fact, it already has some of the things you are claiming it doesn't have - both threads & shared memory are available already in Chrome & Firefox's stable releases ( https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md https://github.com/WebAssembly/threads/blob/master/proposals... & https://webassembly.org/roadmap/ https://webassembly.org/roadmap/ ). Which means it also has accurate timers. WASM very intentionally allows the host to expose whatever feature set it wants. That's a very core design element. You can't just ignore that and focus on the ~nothing that the "spec" itself delivers & pretend that's by-design. WASM isn't a standalone runtime and isn't trying to be.