Spawning operating system processes

[bkolobara]

Sometimes it's useful to just offload the workload to some command line tool. Under the hood, it would just use Rust's process::Command.

We would also need an additional configuration option to add an allow-list for specific processes. By default it would be empty.

It would also be useful to capture the status and output.

[gaolaowai]

[gaolaowai]

I personally think having both a whitelist and blacklist of input filtering, with the blacklist taking precedence in case of collisions, would go a long way towards having an initial security implementation for this.

Hopefully others will comment here as well.

[jgarvin]

I think this would be useful and got here because I was thinking about whether I could build a distributed make like tool on top of lunatic, which would definitely need the ability to spawn OS processes. I think if you're allowing spawning OS processes, you're allowing code to run outside the lunatic runtime, therefore you need security enforced outside the runtime. Lunatic could try to add best effort sanitizing, but in the end I think you need a container/VM outside Lunatic to control what other OS processes that are outside Lunatic's model can do. "Stuff run outside the runtime needs security from outside the runtime" seems fair. You could have a trusted lunatic process that spawns a limited set of OS processes based on messages from other lunatic processes, but that trusted lunatic process in the end still needs some API to call.

It shouldn't be an on-by-default capability and the docs should warn users and encourage them to compile their utilities to WASM and run them inside lunatic instead if possible, but that's not always practical (closed source binaries, maintainers not interested in WASM support, reliance on APIs that don't exist in WASI yet, better native performance, etc).

[anishcr]

I am a newbie to Lunatic, WebAssembly and Rust, so please bare with my queries.

I am looking into the issue and see if i can implement it.

1. What is the configuration option required?

• A simple boolean flag to allow or disallow any commands to be executed?
• A list of commands that are allowed?
  Do we need the users to specify the whole path and/or md5 hash? In case we need md5 hash, do check the hash before executing the command?
  We are not going to check/validate the arguments? (for eg if the user gives rm -rf, we do allow it!)
• A list of commands that are not allowed?
  so any command not in this blacklist is allowed.

2. Wasi folder restrictions
   Looking at this https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-tutorial.md link i got the impression that we need to explicitly specify the folders to which there is read access.

So let's give it capabilities to access files in the requisite directories:

$ wasmtime --dir=. --dir=/tmp demo.wasm test.txt /tmp/somewhere.txt
$ cat /tmp/somewhere.txt
hello world

Do we need to consider this when we allow which all commands can be executed and whether the restriction is applicable to those commands?

3. command which runs infinitely
   What if the command is expecting a user input or it is running infinitely? Do we need a (configurable?) timer which will "kill" the command if it doesn't complete within that time?

@bkolobara gave me some guidance (async, streaming etc) in the discord channel. I will have better clarity (and hopefully better queries) once i complete reading of those links.