❔ A safe scripting language for a Discord bot
Hi there. I'm looking into a system where server owners can design fully custom commands for their server without requiring their own bot, or the main bot to implement it. I've thought about perhaps utilizing Lua for this usecase, but I'm of course concerned about things like privilege escalation or finding a way out of the sandbox, resource exhaustion, and any other issues that would come with letting users effectively run their own code.
Are there any solutions out there that account for this? Lua isn't the only option obviously, I just know it's a common "I want to let users script things without them needing to know the same language the [x] is written in". Some things of note I'd be looking for:
- limiting execution steps or memory usage by the sandbox
- being able to pass in "context" to the sandbox (IE, the channel the custom command was run in, the user executing the command, etc)
6 Replies
there was moonsharp which is integration of lua into C# that has sandboxing that might provide some insight
but I'm unsure if it's still being maintained
you can sandbox environment in .net framework using appdomains but it looks like that approach was not translated over to .net core and the general consensus was to let the host OS permissions control the sandboxing
i.e. running the plugin under a user account with the elevation required
if we take World of Warcraft for example, they use Lua integration but they don't expose any of the io APIs
you can get around this by injecting instructions into the client and "unlocking" the Lua to run what they want but they won't affect users trying to install plugins with this "unlocked" Lua without doing the modification themself
GitHub
GitHub - SteveSandersonMS/DotNetIsolator: A library for running iso...
A library for running isolated .NET runtimes inside .NET - GitHub - SteveSandersonMS/DotNetIsolator: A library for running isolated .NET runtimes inside .NET
I think you should lock down a lot (if not all) APIs, especially ones that have to do with I/O
execution steps - perhaps you could just limit it by time taken?
time taken would be fine, most likely. I don't remember where I read, but someone was writing a scripting language interpreter of some sort that actually kept track of execution steps/lines alongside execution time, meaning someone couldn't just waste resources/cycles with a 1 billion iteration for loop, and that seemed interesting
It kinda sounds unnecessarily complex
I mean, it isn't much but
The point is so that buggy / bad code can't run indefinitely wasting resources
a fixed timeout of some sort seems like a much simple and easier solution
though I wonder how you'd deal with the issues with incomplete states on forced shutdown
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.