[bitbo]

I'm confused. Zellij uses wasmer and wasmer-wasi. Wasmer may use cranelift for compilation (dont know if Zellij does).

"Fast & Safe. Wasmer runs WebAssembly at near-native speed in a fully sandboxed environment." (https://github.com/wasmerio/wasmer)

But ...

"Cranelift does not yet perform mitigations for Specter or related security issues, though it may do so in the future." (https://github.com/bytecodealliance/wasmtime/tree/main/crane...)

Will the wasmer runtime handle specter / meltdown / rowhammer attacks?

[maxmcd]

I feel like in this case those kinds of things are up to Zellij. If you run wasmer within the same process and share memory with the main Zellij process then yes wasmer/cranelift/wasmtime/wasm doesn't protect you from various speculative execution attacks. However, Zellij could run plugins in separate processes and apply things like seccomp to get further protections provided at the operating system level.

This is still not a complete security story and would not provide the same kind of protection as a VM, but I think the charitable take here is that this is a good sandboxing tool and a step in the right direction for something like a plugin system.

edit: I also disagree with the "fully sandboxed" wasmer line, but wasmer is a venture-backed for-profit org that will start selling something at some point and they might have a motivation to blur the lines a little. I appreciate cranelift's more honest disclaimer.

[chc4]

WASM and Wasmer are not intrinsically anymore secure, except for simplicity, than any other editor plugin system. Vimscript and Emacs-lisp basically have the same security characteristics as using WASM for plugins. It's not a step in any direction, except for whatever environment Zellij exposes to the plugins by default.

[maxmcd]

I'm not sure how this is true. I don't know anything about vimscript and emacs-lisp plugin systems, but at a cursory glance it looks like plugins might be able to do things like launch shell commands?

Zellij seems to be using WASI, a standard set of syscalls. Currently, wasi syscalls (or at least the version of wasi that is running in wasmer) can't really access the network, can't fork/exec, can provide a chroot view of the filesystems (without root access), can limit access to certain types of functionality. These kind of secure defaults seem like an improvement to me compared to most plugin systems I'm familiar with.

Maybe vimscript/emacs-lisp has these things.

[tedunangst]

Can you elaborate on the threat model that requires your terminal multiplexer to have rowhammer mitigations?

[maxmcd]

I think OP is just arguing and saying "fully sandboxed" might imply that kind of security.

[bitbo]

Yes, maybe Zellij using Wasmer is great, don't know. I commented because as someone who don't follow the rust ecosystem I was curious if there was something not as big and complicated as google's v8 engine for running sandboxed code.

But it seems you should not use wasmer for running untrusted code or binaries.

I also don't know enough about rowhammer, or security exploit of any kind really, to answer the question about how you could use them against a terminal multiplexer.

[chc4]

It doesn't, nor does it use seccomp to mitigate against language VM security issues.

[syrusakbary]

seccomp should not be needed for a Wasm VM unless the host calls are unsafe, which is not the case by default (since no host functions are provided) or for WASI (since is alreay designed to be sandboxed).

Also, seccomp only works in the Linux kernel (not in Windows, or macOS)... so it's a no-go for a universal sandboxed VM :)