> If you need to run native code, just do so.
Please read the paper; WALI already improves on running native code by being portable and having CFI built in.
> Don't sabotage the only decent chance at finally fixing computer security since Multics to do so.
Wasm has never been about fighting holy wars; I don't think it's productive to ruminate on obliterating all software that doesn't fit one's personal conception of how things should work, no matter how justified it may seem from the inside.
Core Wasm has always been a portable abstraction over hardware; a low-level, but sandboxable bytecode ISA as a compilation target. It's so useful because it's completely separate from the APIs you give Wasm code. It can be embedded into almost any environment by offering an API.
> Capability based security is the main feature of WASM.
The APIs that are exposed to a Wasm can be capability-based or not. It is not inherent to Wasm. The Web APIs are generally not--there are too many ways to circumvent any possible user-level access restrictions in JavaScript. Effectively, the entire JS API surface is available to a Wasm module. That's a property of the Web.
But it's never "game over" for a Wasm module to suddenly get access to the whole world.
What makes Wasm great is that the embedding environment gets to decide how to bind a module's requested bindings to actual bindings, even in an embedding with "dangerous" capabilities. The embedder can decide to interpose, emulate, or otherwise attenuate a module's requested imports, by deciding how to bind to actual implementations. In the case of WALI, because imports are statically named by the module, and bindings are supplied based on those names (rather than by dynamic syscall number), we can statically inspect modules and reject ones that request blacklisted syscalls (or make them nops or whatever you like). You're pretending like a module using one WALI syscall immediately means game over. That's just binary thinking.
Incidentally, there is nothing inherent about WASI that says that the file system has to be sandboxed and capability-based; it's only a convention, which of course can be circumvented by pre-opening the root directory, the proc filesystem, etc--i.e. it's always subject to operator error the embedder level. The embedder decides to do with API bindings; always has, always will.
Besides, this is a first step, a proof of concept.
Of course you wouldn't expose raw, unfiltered WALI calls to untrusted code. (Of course you wouldn't expose WALI to the Web, requiring all Web browsers to emulate Linux.) If you have untrusted code, you still only supply WALI functionality consistent with the capabilities you want it to have, sandboxing any module by limiting, interposing, or blacklisting WALI calls, or building a separate API like WASI on top of WALI and only exposing that. And you can further sandbox the engine itself using techniques for sandboxing processes.