Allowing syscalls in wasmtime for dynamically loaded plugins

Hi. I'm creating text editor. I want to make it modular as neovim.
Neovim uses lua which has access to all kind of stuff that neovim can do (e.g. syscalls).
My editor will load plugins as wasm files in wasmtime runtime. So i've read a little about it and apperantly i can't use syscalls from plugins if host doesn't export those functions.

My question is: Is it really so bad to have the same approach as neovim with lua? As text editor is not something "vulnurable" i guess i can just let plugins do whatever they want. It will make plugins more powerful and all the checks for mallicious software will be on user.

1 Like

And we all know how this will end :slight_smile:

My suggestion would be to at least have the plugin declare whether it can escape the sandbox or not.

1 Like

And in any case how would you even call syscalls from wasm? Wasm doesn't have a syscall instruction and wasm modules are entirely unaware where their linear memory is located within the host process (it may even get relocated when you grow the linear memory), so any syscall that takes an address will not work at all even if you could call syscalls from wasm. Same issue exists for importing arbitrary libc functions.

Actually,i just published a crate to restrict unwanted syscalls called restrict, you can allow opening, reading and writing files, but disallow execve and other possibly malicious syscalls.
just remember that there is always a tradeoff between flexibility and security.

1 Like

Doesn't wasi allows us to use syscalls from wasm? I don't really know the real benefits of allowing wasm to use syscalls but:
I had an idea of creating cli tool to track time spent in text editor and probably in other apps as well. I want it to be independent cli tool and integrate it via plugins which can execute them.

Upd: i think syscalls are able to work because like exported functions, wasi might execute syscalls within host context

That is enough to escape the sandbox if you don't limit which files can be accessed. Simply open /proc/<pid>/mem of an unsandboxed process running as the same user and rewrite its stack to ROP it into running a program of your choosing.

1 Like

You're right — allowing open/write without considering sandbox escapes is dangerous. Simply writing a command to .bashrc can lead to code execution everytime time a bash shell is launched, also, as you mentioned ROP'ing your program into another executable can bypass sandboxing.
I'm working on controlling the syscalls beyond the simple allow/block and provide pre-existing profiles that take into account these cases.