4 ms·

Your links show several aspect of the WASM sandboxing techniques. Don't mixup the core WASM and WASI. The FS sandboxing is actually part of WASI, as core WASM d

Your links show several aspect of the WASM sandboxing techniques. Don't mixup the core WASM and WASI. The FS sandboxing is actually part of WASI, as core WASM doesn't allow any FS access or system calls. > whitelist any and every call This is the default WASM model. It provides no outside calls by default. This works fine for the original web browser model where WASM is essentially just providing a way to run a function from JS with near native speed. It's extremely limited in usefulness but fast and secure. WASI is an effort to provide a set of curated APIs to make it easier to use WASM for more use cases like networking or even printing to a console. > First of all you can forget about C/C++. Everything in this languages assumes free access to the system. C/C++ works fine. It essentially acts like a bare metal embedded device, but without access to hardware registers. You cant even print to console by default. This does means most of the C standard library won't work, but C itself doesn't care. There are no system calls either, only whitelisted functions calls statically provided to the WASM code. Again C/C++ don't care, but it means you can only use code that uses limited subset of the standard library. The JVM's bytecode design makes it hard to translate C to it, whereas WASM is designed for languages like C with arbitrary pointer arithmetic. WASM just turns point access into memory offsets, while the JVM or CLR assume a Java like language. > I don't find any such feature mentioned in the Wasmer docs. It seems completely without any sandbox! Browsers have been shipping WASM VMs for years now without disaster, so apparently they do know whats required for sandboxing. If you can prove otherwise and break out of WASM you could make a lot of money from Google's security bounties or just selling it on the darknet. ;) I'm sure theres been security flaws just like in any sandbox technology, but generally WASM appears successful. Its been adopted outside browsers by security conscious companies like cloud-flare and fastly to provide sandboxing of user code, etc. > (To stress it once more: All VM languages are memory safe. That's not sandboxing. All the "sandboxed by default" claims are misleading, at least). You're correct that limiting memory access is only part of what a sandbox requires. Memory safety is a crucial piece of sandboxing, though many VMs do provide that. However most VMs also provide mechanisms to escape the memory sandbox though so they're not good at being sandboxes. The other crucial part for sandboxing is control flow. The VM must prevent code from being able to hijack control flow, or to otherwise generate code to escape the sandbox. The links you provided discuss how WASM does this currently: > All control transfers—direct and indirect branches, as well as direct and indirect calls—are to known and type-checked destinations, so it's not possible to accidentally call into the middle of a function or branch outside of a function. What most of the hype around WASM is actually about is the ability to provide this sandbox isolation after translating WASM bytecode to native binary code. Most JVM VMs also do JIT'ing at runtime, but the JVM has some runtime features and assumptions that make statically compiling upfront harder. WASM was designed to enable ahead of time compiling from the outset. That is a key difference between JVM and WASM. For example here's a paper from Stanford & UC folks for a static verification engine for checking that binary executables translated from WASM to maintain the sandboxing: https://cseweb.ucsd.edu//~dstefan/pubs/johnson:2021:veriwasm.pdf https://cseweb.ucsd.edu//~dstefan/pubs/johnson:2021:veriwasm... > One should never over promise on security! Java had to learn this the hard way over many years (as their sandbox had have holes in the past, and was also almost impossible to correctly configure). To reiterate, WASM incorporated these details from the outset, to the point that providing useable WASM VMs outside of browsers years to come about. If you're talking about WASI, you have a bit more of a point. WASI is the result of carefully adding back in things like FS access using capabilities and other techniques to keep it sandboxed. This is harder, and introduces more surface area to violate WASM's sandboxing. However WASI seems well thought out so far.

kaba0 4y ago
I really don’t want to sound argumentative just for the sake of it, but sandboxing through “not allowing any side effecting things” is quite.. trivial? Like, I have written a brainfuck interpreter and it can only do prints to stdout, so it is guaranteed safe, hell, it is quite good as a compile target! There is nothing inherent in java bytecode that would make it unsafe, nor hard to AOT compile — runtime reflection is not part of the JVM spec itself, it is a separate API (akin to WASI) that provides this capability. So, a JVM interpreter can also do no harm without attaching the endpoints that can do harm obviously. Also, there used to be a project called gcj 20 years ago that managed to AOT compile java just fine, the only riddle here is the aforementioned reflection. Graal uses a closed-world assumption to solve it. Your link is interesting though, will look into it.
- still_grokking 4y ago
  > Your link is interesting though, will look into it. Looks much like the byte-code verifier that is std. part of the JVM. The foundations on which this is built look quite solid though.
still_grokking 4y ago
### PART 2 (as the comment was too long for the system here) ###: > > One should never over promise on security! Java had to learn this the hard way over many years (as their sandbox had have holes in the past, and was also almost impossible to correctly configure). > To reiterate, WASM incorporated these details from the outset, to the point that providing useable WASM VMs outside of browsers years to come about. Could it be that you just again confused "sandboxing" and memory safety? The problem with the JVM sandbox (and most of the time other VM languages) isn't memory safety! There have been such bugs here and there, sure. In the JS VMs, the WASM WMs (like pointed out in the above linked paper), and also the JVMs. But those bugs are the usual implementation bugs. Once again, this is not relevant to the questions here. Memory safety is not a "sandbox"! > WASI is the result of carefully adding back in things like FS access using capabilities and other techniques to keep it sandboxed. What "sandbox" are you talking about? There is only one WASI implementation that offers a extremely simple FS access filter. (And Wasmer, which we're taking about here, does not even have that, as I see it). Capability security? Where is this implemented? One again: I don't talk about what people dreamed up! I'm asking for the status quo. > This is harder, and introduces more surface area to violate WASM's sandboxing. Yes, that's the point. Having a cage that does not let anything through is easy. Just build massive walls without windows and doors. Nothing can get out. Nothing can get in… But such a cage is almost useless. So the interesting part starts when a thing in the cage needs to talk to the outside world! "Solving" the "trivial" problem is indeed easy. Now show me how you solve the real problem! But to my knowledge there is nothing there. Nothing. (Besides promises and cool sounding plans for some distant future). > However WASI seems well thought out so far. Yes, "thought out". But not implemented! BTW: They did not come up with anything new here. Capability security is at least around 40 years old. The point is: Nobody ever implemented this outside of academia. We have just now the first steps in that direction. But that are at best beta versions of tech form the future… As it stands today: WASM does not have any meaningful sandbox. (Memory safety is not a sandbox! It's "just" a prerequisite to be able to implement a sandbox. But it's not one by itself, and a feature _every_ VM runtime provides). Even containers will give you more sandboxing based on the (by now) rich features of Linux namespaces. (Still nobody considers this a serous sandbox on which you could bet your ass. That's why we run containers in VM; because that's the only—more or less—reliable sandbox we currently have; as our OSes and hardware still don't provide capability security features). --- Don't get me wrong though. I do think that the whole "linear memory" idea for memory safety is indeed a very good one. It's so good, I think this should be implemented on the HW level! (Or at least in a first step on the OS level). But "really safe memory cages" aren't sandboxes. Without capability security on top this does not provide any meaningful improvement over what we have already since decades. But capability security isn't something that you can just to piggyback after the fact. Everything, form the languages used and their libs, up through the OS and VM layers need to be explicitly build with this mechanism in mind. We're still light years away form having such infrastructure! But what the WASM people present is some fantasy world where all this is already in place. Given how aggressive those obvious lies are pushed I can't come to any other conclusion than that there is a lot of bad faith behind this campaigns. "Someone" tries to push by all means their VM tech into the market. Even they're leaking around 20 years behind the next competitor. This whole thing is a disgusting marketing war. And to be honest I'm quite scared how effective this ultra aggressive marketing is even it's almost completely based on highly over promised stuff up to, in its extreme, blatant lies. I hope the person I'm talking to here isn't part of this marketing effort. And people reading this start to ask themself the "right questions" finally ;-).

kaba0 4y ago

I really don’t want to sound argumentative just for the sake of it, but sandboxing through “not allowing any side effecting things” is quite.. trivial? Like, I have written a brainfuck interpreter and it can only do prints to stdout, so it is guaranteed safe, hell, it is quite good as a compile target! There is nothing inherent in java bytecode that would make it unsafe, nor hard to AOT compile — runtime reflection is not part of the JVM spec itself, it is a separate API (akin to WASI) that provides this capability. So, a JVM interpreter can also do no harm without attaching the endpoints that can do harm obviously. Also, there used to be a project called gcj 20 years ago that managed to AOT compile java just fine, the only riddle here is the aforementioned reflection. Graal uses a closed-world assumption to solve it. Your link is interesting though, will look into it.

still_grokking 4y ago
> Your link is interesting though, will look into it. Looks much like the byte-code verifier that is std. part of the JVM. The foundations on which this is built look quite solid though.

still_grokking 4y ago

### PART 2 (as the comment was too long for the system here) ###: > > One should never over promise on security! Java had to learn this the hard way over many years (as their sandbox had have holes in the past, and was also almost impossible to correctly configure). > To reiterate, WASM incorporated these details from the outset, to the point that providing useable WASM VMs outside of browsers years to come about. Could it be that you just again confused "sandboxing" and memory safety? The problem with the JVM sandbox (and most of the time other VM languages) isn't memory safety! There have been such bugs here and there, sure. In the JS VMs, the WASM WMs (like pointed out in the above linked paper), and also the JVMs. But those bugs are the usual implementation bugs. Once again, this is not relevant to the questions here. Memory safety is not a "sandbox"! > WASI is the result of carefully adding back in things like FS access using capabilities and other techniques to keep it sandboxed. What "sandbox" are you talking about? There is only one WASI implementation that offers a extremely simple FS access filter. (And Wasmer, which we're taking about here, does not even have that, as I see it). Capability security? Where is this implemented? One again: I don't talk about what people dreamed up! I'm asking for the status quo. > This is harder, and introduces more surface area to violate WASM's sandboxing. Yes, that's the point. Having a cage that does not let anything through is easy. Just build massive walls without windows and doors. Nothing can get out. Nothing can get in… But such a cage is almost useless. So the interesting part starts when a thing in the cage needs to talk to the outside world! "Solving" the "trivial" problem is indeed easy. Now show me how you solve the real problem! But to my knowledge there is nothing there. Nothing. (Besides promises and cool sounding plans for some distant future). > However WASI seems well thought out so far. Yes, "thought out". But not implemented! BTW: They did not come up with anything new here. Capability security is at least around 40 years old. The point is: Nobody ever implemented this outside of academia. We have just now the first steps in that direction. But that are at best beta versions of tech form the future… As it stands today: WASM does not have any meaningful sandbox. (Memory safety is not a sandbox! It's "just" a prerequisite to be able to implement a sandbox. But it's not one by itself, and a feature _every_ VM runtime provides). Even containers will give you more sandboxing based on the (by now) rich features of Linux namespaces. (Still nobody considers this a serous sandbox on which you could bet your ass. That's why we run containers in VM; because that's the only—more or less—reliable sandbox we currently have; as our OSes and hardware still don't provide capability security features). --- Don't get me wrong though. I do think that the whole "linear memory" idea for memory safety is indeed a very good one. It's so good, I think this should be implemented on the HW level! (Or at least in a first step on the OS level). But "really safe memory cages" aren't sandboxes. Without capability security on top this does not provide any meaningful improvement over what we have already since decades. But capability security isn't something that you can just to piggyback after the fact. Everything, form the languages used and their libs, up through the OS and VM layers need to be explicitly build with this mechanism in mind. We're still light years away form having such infrastructure! But what the WASM people present is some fantasy world where all this is already in place. Given how aggressive those obvious lies are pushed I can't come to any other conclusion than that there is a lot of bad faith behind this campaigns. "Someone" tries to push by all means their VM tech into the market. Even they're leaking around 20 years behind the next competitor. This whole thing is a disgusting marketing war. And to be honest I'm quite scared how effective this ultra aggressive marketing is even it's almost completely based on highly over promised stuff up to, in its extreme, blatant lies. I hope the person I'm talking to here isn't part of this marketing effort. And people reading this start to ask themself the "right questions" finally ;-).