Security issues with using yaegi in production? And how do i work around them?

[ishaan812]

I want to use Yaegi in Production. But letting the user freely enter code seems to me that we are opening up to a lot of security issues. Wanted to know how other people have worked around them.

[mvertes]

In a nutshell, here is what we do in Yaegi to address security in presence of untrusted scripts:

• No access to unsafe package: a script has no simple way to access and manipulate memory outside its scope.
• Sensitive system calls are disabled or virtualised: call to os.Exit() doesn't exit, it just terminates the interpreter. os/exec is simply disabled, as for some syscall (i.e. fork(), etc.
• All panics are catched and propagated to the interpreter caller function in host. Again, there is no obvious way for a script to terminate the host process.
• standard input, output and error are per interpreter session, independent of host. It applies to multiple stdlib packages, such as fmt, log, etc.
• Environment is virtualised per interpreter session, a script can not change the env of his host process.

All of this is on top of the security features already present in the Go runtime, such as type checking (Yaegi only manipulates reflect.Values), and the first level of sandboxing of the interpreter virtual machine.

It has been possible to enable the same kind of sandboxing and restrictions that you find in smartphones apps with regard to their runtime, by overloading the Go standard library, simply and at a few critical places.

We recognize the excellent design and architectural choices made by the Go team, security wise, for the runtime and standard library. We simply try to preserve it and build on top of it.

For some examples of how it is used in production, you can have a look at the plugins catalog of traefik, all powered by yaegi.