5 ms·

Java had an extremely advanced and strict sandbox for many years. It offered of course also the possibility to blacklist everything by default. The problem wi

Java had an extremely advanced and strict sandbox for many years. It offered of course also the possibility to blacklist everything by default. The problem with such a granular sandbox is that it's too complex for most use cases. When you need to whitelist any and every call to the outside world this becomes very tedious. That's why Java now removes the sandbox… https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/ https://inside.java/2021/04/23/security-and-sandboxing-post-... Let's see how this works out for WASM. I guess: Without resorting to using some language(s) with build-in support for capability security a whitelist based sandbox approach won't ever work without issues. First of all you can forget about C/C++. Everything in this languages assumes free access to the system. Rust does not have any support for capabilities either (yet, and for the years to come at least). The best current WASM sandbox implementation, which is in WasmTime not Wasmer, is not more than a FS block. (And the memory safety guaranties you get in any VM language, of course). https://docs.wasmtime.dev/security.html https://docs.wasmtime.dev/security.html I don't find any such feature mentioned in the Wasmer docs. It seems completely without any sandbox! (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). https://github.com/wasmerio/wasmer/issues/221 https://github.com/wasmerio/wasmer/issues/221 That even people here on HN believe in the currently unfulfilled WASM security promises shows only how good the WASM marketing is. This should make you even more skeptical. 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).

syrusakbary 4y ago
> I don't find any such feature mentioned in the Wasmer docs. It seems completely without any sandbox! That's not correct. Wasmer aims to be a fully sandboxed WebAssembly Runtime. Wasmer WASI implementation is also fully sandboxed.
- still_grokking 4y ago
  > Wasmer WASI implementation is also fully sandboxed. Could you please link to some authoritative documentation for that? As I said I don't see this in any docs or GitHub sources. The point is: It's irrelevant what they "aim for". The only interesting thing at the moment is the status quo.
  - syrusakbary 4y ago
    Sure thing. Check the WASI README (a section was just added to clarify your comment) https://github.com/wasmerio/wasmer/blob/master/lib/wasi/README.md https://github.com/wasmerio/wasmer/blob/master/lib/wasi/READ...
    - still_grokking 4y ago
      Thanks for the effort! I still don't get it. What does "the aim to be 'fully sandboxed'" mean in the light of "support [of] standard I/O, file I/O, filesystem manipulation, memory management, time, string, environment variables, program startup etc."? What are "secure systemcalls"? What does this mean on the technical level? How is the simple FS access filter (something you get form std. Unix FS access rights since 50 years) something special here, or even considered "fully sandboxed"? (I get the broader idea of capabilities. But I would see this only as a minor implementation detail in the current state).
      - syrusakbary 4y ago
        Basically, what we mean by sandboxed is that the application would not be able to do anything harmful to your system unless explicitly allowed (similar ethos as Deno, compared to NPM). Let me explain a bit more how: * stdio / file io: thanks to Wasmer VFS and the WASI mapped dirs, the application will only able to access to the directories explicitly defined by the user when running a program. Any file/dir access outside of the allowed directories will throw an error (both by design of WASI and by our implementation of it). Note: by default stdout/stderr will be piped but that can also be easily customized. * Environment variables: no environment variables can be accessed unless explicitly specified to our CLI (or SDKs) * Time: we consider time access (get) to be harmless (WASI don't allow setting the platform/OS time, so we don't have to worry about that) > What are "secure systemcalls"? What does this mean on the technical level? It means system calls that we consider harmless to execute. For example, getting the current time (unix timestamp) is considered harmless by our WASI implementation (it should be easy to even shield that, if needed), but accessing a file could be harmful (that's why we ask for permission first). Of course, no software is free from bugs that could jailbreak the sandbox, specially after Spectre and Meltdown. So having something to be "fully sandboxed" is an infinite game. But our aim is there, nonetheless :)
elcritch 4y ago
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.

syrusakbary 4y ago

> I don't find any such feature mentioned in the Wasmer docs. It seems completely without any sandbox! That's not correct. Wasmer aims to be a fully sandboxed WebAssembly Runtime. Wasmer WASI implementation is also fully sandboxed.

still_grokking 4y ago
> Wasmer WASI implementation is also fully sandboxed. Could you please link to some authoritative documentation for that? As I said I don't see this in any docs or GitHub sources. The point is: It's irrelevant what they "aim for". The only interesting thing at the moment is the status quo.
- syrusakbary 4y ago
  Sure thing. Check the WASI README (a section was just added to clarify your comment) https://github.com/wasmerio/wasmer/blob/master/lib/wasi/README.md https://github.com/wasmerio/wasmer/blob/master/lib/wasi/READ...
  - still_grokking 4y ago
    Thanks for the effort! I still don't get it. What does "the aim to be 'fully sandboxed'" mean in the light of "support [of] standard I/O, file I/O, filesystem manipulation, memory management, time, string, environment variables, program startup etc."? What are "secure systemcalls"? What does this mean on the technical level? How is the simple FS access filter (something you get form std. Unix FS access rights since 50 years) something special here, or even considered "fully sandboxed"? (I get the broader idea of capabilities. But I would see this only as a minor implementation detail in the current state).
    - syrusakbary 4y ago
      Basically, what we mean by sandboxed is that the application would not be able to do anything harmful to your system unless explicitly allowed (similar ethos as Deno, compared to NPM). Let me explain a bit more how: * stdio / file io: thanks to Wasmer VFS and the WASI mapped dirs, the application will only able to access to the directories explicitly defined by the user when running a program. Any file/dir access outside of the allowed directories will throw an error (both by design of WASI and by our implementation of it). Note: by default stdout/stderr will be piped but that can also be easily customized. * Environment variables: no environment variables can be accessed unless explicitly specified to our CLI (or SDKs) * Time: we consider time access (get) to be harmless (WASI don't allow setting the platform/OS time, so we don't have to worry about that) > What are "secure systemcalls"? What does this mean on the technical level? It means system calls that we consider harmless to execute. For example, getting the current time (unix timestamp) is considered harmless by our WASI implementation (it should be easy to even shield that, if needed), but accessing a file could be harmful (that's why we ask for permission first). Of course, no software is free from bugs that could jailbreak the sandbox, specially after Spectre and Meltdown. So having something to be "fully sandboxed" is an infinite game. But our aim is there, nonetheless :)

elcritch 4y ago

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.