Mirror of forum.nim-lang.org

6646 :: Sandboxing untrusted Nimscript code

• sekao (orginal) [2020-08-06T16:28:35+02:00] view original

  I'd like to find a way to safely run arbitrary Nimscript code. That would require finding a way to disallow unsafe actions, such as disk and network IO. Does anyone have suggestions on the best way to achieve this?

  I know you could compile the code with Nim's JS backend or compile to web assembly, but i'm hoping for a solution that just works on the Nimscript interpreter without any additional runtime.

---

• juancarlospaco (orginal) [2020-08-06T20:33:15+02:00] view original

  Just chop off the parts of the std lib that you consider too risky (?), you can not do much if you can not import much stuff, maybe some stuff on system still risky.

  If you are on Linux theres a firejail package.

---

• zevv (orginal) [2020-08-06T22:28:43+02:00] view original

  Nim playground works by spawing the compiler in a docker container. Might be overkill but it seems pretty effective.

---

• leorize (orginal) [2020-08-07T00:55:38+02:00] view original

  See https://github.com/nim-lang/Nim/blob/devel/compiler/scriptconfig.nim#L85 and https://github.com/nim-lang/Nim/blob/devel/compiler/vmops.nim for how the nimscript VM is configured. By tweaking the implementation of IO-related procs, you can effectively sandbox nimscript. This is already being done for nimsuggest/nim check.

---

• dsrw (orginal) [2021-06-28T20:37:10+02:00] view original

  I'll also be running untrusted nimscript code in the not too distant future. I was planning to rely on os provided process sandboxing, but being able to lock down nimscript as suggested here would make my life easier. What's the general confidence level that this would actually work?

  Can I lock down staticRead/staticExec? Should I assume that the code running in the nim VM can't read arbitrarily from my process's memory?

  I expect I'll still use os sandboxing in my official builds, but that doesn't do anything to protect the data in my process, so protection at the vm level would be very nice.

---

• Araq (orginal) [2021-06-28T20:55:23+02:00] view original

  Do not define the nimcore conditional symbol and then the VM does not offer staticExec/staticRead anymore. You also need to ensure that vmopsDanger is not set in c.config.features. I claim the VM's sandboxing is then very good.

---

• dsrw (orginal) [2021-06-28T21:08:02+02:00] view original

  I claim the VM's sandboxing is then very good.

  That's really great to hear. Thank you very much.

---

• timothee (orginal) [2021-06-29T01:57:43+02:00] view original

  Do not define the nimcore conditional symbol and then the VM does not offer staticExec/staticRead anymore.

  @araq this requires recompiling nim, which shouldn't be required for the OP's request. instead, we should have:

  • --experimental:vmopsDanger: allows un-restricted access to APIs (more APIs can be added in vmops, yes, even os.removeFile etc ; once you have gorge you can do just as much damage but it's more error prone); note that this can (or at least could) be usable with push/pop contexts. This avoids having to patch working RT code to work at CT with when nimvm: uglyWorkaround()
  • --experimental:vmsandbox: disables APIs like gorge + friends

  refs: https://github.com/nim-lang/Nim/pull/16943#issuecomment-773980301 and https://forum.nim-lang.org/t/5315#48992 which discussed pretty much exactly the same topic

---

• Araq (orginal) [2021-06-29T07:11:25+02:00] view original

  @araq this requires recompiling nim, which shouldn't be required for the OP's request

  Er, I think he uses Nim's VM directly and the Nim compiler as a library.

---