Is tengo safe for external scripts?

[pedrolvr]

I need to execute the possibly untrusted scripts sent by users and I would like knowing if Tengo could be used for that.

[geseq]

If they’re untrusted and you aren’t running tengo in some sort of secured sandbox, I wouldn’t recommend it (not just with tengo mind you, but with any language)

[d5]

Hard to guarantee anything without knowing what kind of untrusted code you want to run, but, Tengo is "relatively" more secure because the script is compiled into bytecode and run in a VM (whereas other runtime interpreter might expose more vulnerabilities). Also you can control which packages you want to allow for the user script. And, there's no easy way to set the maximum memory usage, but, you can set the maximum number of objects the user script can create instead.

[pedrolvr]

Thanks guys for the answers. The feature is to run code from users like Salesforce after record events, such as save/update/delete/checkout/... One way to add triggers.

[d5]

If you're going to write your own packages (to interact with external services for example), I think Tengo is fairly safe to run the user code. See https://github.com/d5/tengo/blob/master/docs/interoperability.md#sandbox-environments.

[pedrolvr]

Great! I understood that I can create a minimum environment for the user with controlled functions to access external or internal (db queries by id, ...) resources in a safe way.

[ozanh]

Hi @phenrigomes , I'd like to add a few of my experiences. I hope it helps.

• Always run with context having a timeout.
• Do good cleanup, there is no exception handler.
• Do not share your compiled scripts between gorouties.
• Check built-in module implementations if you expose them, e.g. do not give access to os or times.sleep().
• Do not rely on allocation limits as mentioned before, e.g. copy built-in function can easily exceeds the limits in a loop.
• Security related bugs may be shared before a release, add watch to Tengo github account and keep your library up to date.
• Do not hesitate to ask for help.
• Be ready for sql injection if you give access to db operations or building sql strings.

[d5]

• Do not rely on allocation limits as mentioned before, e.g. copy built-in function can easily exceeds the limits in a loop.

Haha. That's a good one.

There's no easy way to control/limit memory allocations in Go in general.

[siff-duke]

It would be good if time.sleep() is in in the os module. I'm not importing the os module but need the times module for parsing and time calcs.

[niemeyer]

Hello all. Arriving a bit late, but thanks for the interesting discussion here.

Was there ever a discussion about solving the case of copy? Maybe an argument or extra return parameter that helps accounting for the changes performed? It might actually be a nice general idea to allow extension functions to collaborate with the accounting, so it becomes a bit more realistic.

Also, is there any other known case of stronger deviations on the allocation accounting?