3 ms·

Right. WASM will protect the server from the apps, which means you don't need to audit or trust what you run. That old PHP website? Compile to WASM and you migh

by irq-1 5y ago

Right. WASM will protect the server from the apps, which means you don't need to audit or trust what you run. That old PHP website? Compile to WASM and you might lose any data it can touch, but it won't expose the server in any way -- no getting a login shell or sudo exploits, etc...

nerdponx 5y ago
Forgive me if this is a newbie question, but what makes the Wasm runtime more of a "sandbox" than e.g. CPython or the JVM? Do you need explicit permission/authorization from the host machine in order to do things like file and network i/o? Surely such a system isn't any more foolproof than SSH w/ a restricted shell, KVM, etc.?
- irq-1 5y ago
  Web Assembly comes from JavaScript on the client, which means: -it's extremely secure, tested for many years, etc... -it's different than other VMs, almost no types or functions, the VM cannot access outside memory, only call functions supplied by the host (or write to stdout, again supplied by the host.) -It loads fast, runs fast. Browser JavaScript has been very optimized. -unrelated to the browser, but many languages can be compiled to WASM What you see in this project is the WASI interface that provides the normal libc functions like fopen(), allowing WASM to act like a normal binary. But you can run WASM with other sets of functions, or none and the host can do all the moving of bytes. Cloudflare, Netlify and others are trying to figure out how to host WASM for cloud functions because it's perfect for their systems: small, fast and safe.
  - nextaccountic 5y ago
    I think there are some misconceptions here. Wasm on the server using WASI (which nowadays is probably either wasmtime or wasmer) doesn't have anything to do with Javascript. Actually, wasm on the browser doesn't have anything to do with javascript either! This is actually unfortunate, because wasm in the browser can't natively interface with JS's GC yet [0]. On the other hand, I think a great strength of wasm is that wasm isn't tied to a single memory management system: if it forced a GC on you, it would also need to dictate the memory layout, and would need to determine how this GC gets run, all this would add unnecessary overheard and inflexibility when compiling low-level languages. Or when compiling any language that don't quite conform to the memory management model, different languages want to manage memory differently. This is a pain in the JVM and wasm fixed that. Another strength is vendor neutrality. All major browsers embraced wasm, and it's got multiple implementations in the server as well. There isn't really a dominant implementation that others must conform, and wasm tools are interoperable between implementations. There are also embedded implementations (I know of wamr and wasm3). On a darker note, I'm sad to see see one WASI runtime bashing another [1]; I wish the competition was more cordial, or at least, more professional. [0] see the issues in this repo https://github.com/WebAssembly/gc https://github.com/WebAssembly/gc [1] https://wasmer.io/wasmer-vs-wasmtime https://wasmer.io/wasmer-vs-wasmtime - makes outlandish claims and uses benchmarks without clearly specifying what is being benchmarked (ideally it would link to a Github repo)
- chrismorgan 5y ago
  It’s the difference between sandboxing and true isolation, between blacklisting and whitelisting. With something like CPython or the JVM, you’re attempting to sandbox something that was designed to be able to run arbitrary code, and was never designed to be restrained in this way, and if you miss even one thing, it’s completely broken. https://web.mit.edu/jesstess/www/pytennessee_sandbox.pdf https://web.mit.edu/jesstess/www/pytennessee_sandbox.pdf is a good summary of what a problem this is, and why it’s basically impossible to secure that way: you’re plugging a huge number of leaks in a massive surface area, and you will not get it watertight—to say nothing of the fact that lots of software depends on those leaks existing (for perfectly benign reasons). And every C extension that you load increases the vulnerable surface area (e.g. https://www.hebergementwebs.com/news/escape-a-python-sandbox-with-a-memory-corruption-bug https://www.hebergementwebs.com/news/escape-a-python-sandbox... describes using a numpy bug to escape a CPython sandbox). You just can’t run a successful sandbox inside CPython or the JVM; instead, you must run the language inside a sandbox—and even that is often troublesome. WebAssembly, on the other hand, is isolated. There are no leaks, and the surface area is tiny, because it was designed that way. It can’t do anything directly save computation on what it’s given; it depends on the runtime to grant it access to any external resources. This completely guards against all direct attacks, leaving only side-channel attacks, which are a vastly less dangerous class in general, and easier to guard against once you know about them, because the runtime controls execution.

by irq-1 5y ago

nerdponx 5y ago

Forgive me if this is a newbie question, but what makes the Wasm runtime more of a "sandbox" than e.g. CPython or the JVM? Do you need explicit permission/authorization from the host machine in order to do things like file and network i/o? Surely such a system isn't any more foolproof than SSH w/ a restricted shell, KVM, etc.?

irq-1 5y ago
Web Assembly comes from JavaScript on the client, which means: -it's extremely secure, tested for many years, etc... -it's different than other VMs, almost no types or functions, the VM cannot access outside memory, only call functions supplied by the host (or write to stdout, again supplied by the host.) -It loads fast, runs fast. Browser JavaScript has been very optimized. -unrelated to the browser, but many languages can be compiled to WASM What you see in this project is the WASI interface that provides the normal libc functions like fopen(), allowing WASM to act like a normal binary. But you can run WASM with other sets of functions, or none and the host can do all the moving of bytes. Cloudflare, Netlify and others are trying to figure out how to host WASM for cloud functions because it's perfect for their systems: small, fast and safe.
- nextaccountic 5y ago
  I think there are some misconceptions here. Wasm on the server using WASI (which nowadays is probably either wasmtime or wasmer) doesn't have anything to do with Javascript. Actually, wasm on the browser doesn't have anything to do with javascript either! This is actually unfortunate, because wasm in the browser can't natively interface with JS's GC yet [0]. On the other hand, I think a great strength of wasm is that wasm isn't tied to a single memory management system: if it forced a GC on you, it would also need to dictate the memory layout, and would need to determine how this GC gets run, all this would add unnecessary overheard and inflexibility when compiling low-level languages. Or when compiling any language that don't quite conform to the memory management model, different languages want to manage memory differently. This is a pain in the JVM and wasm fixed that. Another strength is vendor neutrality. All major browsers embraced wasm, and it's got multiple implementations in the server as well. There isn't really a dominant implementation that others must conform, and wasm tools are interoperable between implementations. There are also embedded implementations (I know of wamr and wasm3). On a darker note, I'm sad to see see one WASI runtime bashing another [1]; I wish the competition was more cordial, or at least, more professional. [0] see the issues in this repo https://github.com/WebAssembly/gc https://github.com/WebAssembly/gc [1] https://wasmer.io/wasmer-vs-wasmtime https://wasmer.io/wasmer-vs-wasmtime - makes outlandish claims and uses benchmarks without clearly specifying what is being benchmarked (ideally it would link to a Github repo)
chrismorgan 5y ago
It’s the difference between sandboxing and true isolation, between blacklisting and whitelisting. With something like CPython or the JVM, you’re attempting to sandbox something that was designed to be able to run arbitrary code, and was never designed to be restrained in this way, and if you miss even one thing, it’s completely broken. https://web.mit.edu/jesstess/www/pytennessee_sandbox.pdf https://web.mit.edu/jesstess/www/pytennessee_sandbox.pdf is a good summary of what a problem this is, and why it’s basically impossible to secure that way: you’re plugging a huge number of leaks in a massive surface area, and you will not get it watertight—to say nothing of the fact that lots of software depends on those leaks existing (for perfectly benign reasons). And every C extension that you load increases the vulnerable surface area (e.g. https://www.hebergementwebs.com/news/escape-a-python-sandbox-with-a-memory-corruption-bug https://www.hebergementwebs.com/news/escape-a-python-sandbox... describes using a numpy bug to escape a CPython sandbox). You just can’t run a successful sandbox inside CPython or the JVM; instead, you must run the language inside a sandbox—and even that is often troublesome. WebAssembly, on the other hand, is isolated. There are no leaks, and the surface area is tiny, because it was designed that way. It can’t do anything directly save computation on what it’s given; it depends on the runtime to grant it access to any external resources. This completely guards against all direct attacks, leaving only side-channel attacks, which are a vastly less dangerous class in general, and easier to guard against once you know about them, because the runtime controls execution.