The language is memory safe, so it is theoretically limited to the surface area that the non-memory-safe OS libraries allow. Of course, that is assuming there are no exploits in the WebAssembly compiler, and no exploits in the OS libraries.

Access to syscalls would not be unusual in any case. This is the normal attack surface for an OS. The new attack surface is the WebAssembly compiler and checker.

To be honest though, given the processor vulnerabilities that have come about, I don't know if I really feel so bad about software protections like this anymore. Nothing is a panacea, even magical processor protection rings.

I don't see how to square "makes essentially arbitrary syscalls so we can run faster than Linux code" and "is safe". WebAssembly is not Platonically safe; it's safe for specific reasons. If you bind syscalls into it, or more generally, bind anything that allows you to do what syscalls do in an OS, you're going to be poking holes in its safety at a distressing pace, because you're taking some of the reasons WebAssembly is safe, and throwing them away.

It may be memory safe, but honestly, memory-safety is no great trick anymore... pretty much everything except the languages currently used to implement kernels is memory safe. Memory safe is still not "generally safe".

About as safe as other managed languages...the security here is dependent on how well implemented the sandbox is.