Sandboxing

[jacobsebek]

As if the fact that the compiler automatically registers functions that allow executing arbitrary code on the host machine wasn't sad enough, external functions cannot even be removed or overwritten because of this.

While this is a single GitHub issue, it's more of a symptom of an entire cascade of security atrocities I have noticed in the design of the language. If I myself don't find the time for this, I strongly advise anyone interested to carefully rethink the integration of Umka as an embedded language and ideally make it as minimal by default in that mode. This lack of sandboxing and other issues like arbitrary C function prototypes render Umka down-right unusable for any serious embedded applications where the goal is to provide a safe, controlled environment to execute untrusted code (imagine any place where 3rd party Umka code is desired, such as a game client fetching custom plug-ins from a server.) It wouldn't even be shameful to just not pretend that Umka is an embeddable language and focus the efforts on the (C-extendable) stand-alone build.

I think that in its essence, Umka is a very nice and clean language with a lot of potential, but we should perhaps get our goals straight.

[vtereshkov]

@jacobsebek Yes, there are some known issues that may cause vulnerabilities (#82, #83). However, I would like to discuss all these issues in the context of a real-life project where they become critical. What potential usages are you considering? Why is sandboxing so important for your project?

I would also prefer to split the problems into several GitHub issues for better tracking. "An entire cascade of security atrocities" is too vague and emotional to be a statement of a problem.

Last but not least, Umka is already used as an embedded language. I'm not going to declare these usages accidental, unintended or undesirable.

[skejeton]

The real problem will arise from network user scripts. For example a game like Garry's Mod needs to run Lua on client side, the Lua code must be properly sandboxed or otherwise you can execute arbitrary code. This mostly does not pose a problem when you use Umka as a language for scripting local game files, however downloading untrusted scripts automatically (which in some scenarios is very likely), will make a huge security problem.

[jacobsebek]

Yes, and even when not downloaded automatically, you can't trust any Umka code from 3rd parties. A sandboxed environment would give you the guarantee of not doing weird stuff, as long as you can trust the host application that embeds Umka and Umka itself.

This is a fundamental trait I thought any embedded language should put as the number one priority, but indeed, to paraphrase Vasiliy, it's not a vulnerability until it's a vulnerability.

[vtereshkov]

For now, a simple sandbox mode is implemented. umkaInit() accepts two additional boolean flags that control whether the Umka script can access the file system and whether it can run native code from shared libraries (UMIs).

@skejeton @marekmaskarinec Please notice that the umkaInit() signature has changed.

[skejeton]

@vtereshkov does this remove system function from stdlib?

[skejeton]

I think @jacobsebek is overly cautious about third party code. It's a threat, but so long you consensually download it, the responsibility is on you. The good reason for not sandboxing is allowing a wider range of functions. This is interesting for things like game mods where you can load a UMI module to do something faster or to interact with a certain API. Minecraft Java certainly is the prime example of that. Community has made correct institutions to manage trusted mods. And I've never got any malware from a Minecraft mod.

Same with Terraria, except there's a curated mod list. On the other having sandboxed mods is nice for all community content to be trusted. It's certainly nice to have sandbox out of the box.

[vtereshkov]

@vtereshkov does this remove system function from stdlib?

@skejeton Yes, it does. Or, more precisely, it replaces this function with a stub.