Is there a compelling reason you didn’t simply call luaL_openlibs() in your setup? This inhibits a lot of normal functionality. I feel this is much like telling a cook to bone out a chicken or prep vegetables with a butter knife. It’s the responsibility of the script writer to avoid doing stupid/expensive stuff in the process() function. A good cook will use sharp knives and still live life with all his fingers attached.
Security.
If you load FFI, you’re already shafted there. At some point you will need to trust the user not to do bad things. There are many many many ways of shooting yourself in the foot with LuaJIT. I’m not sure that a halfhearted attempt at sandboxing buys much beyond annoyance.
May I be blunt and say this is the wrong way to go. If you aren’t willing to audit scripts, maybe you shouldn’t be running them at all. LuaJIT is a general purpose language, and it is going to give you much the same weakness as any general purpose language in this context. I don’t feel that the VCV infrastructure maintainers should consider themselves on the hook for bad scripts that might get loaded. The demo scripts that are bundled touch none of the tricky bits. Speaking as someone who has done serious work with LuaJIT (drone tech), I’m more upset at axing features than the notion that you can load bad code. You can always load bad code via a DLL/so. How does making it Lua really change the picture? If I’m really that scared of the code, shouldn’t I be running VCV Rack in a container anyhow?
Because it follows from the response I reacted to. Also, it’s a style/philosophy of code thing rather than a bug. I tend to report bugs on github issues. Sorry if I upset.
Here’s the github issue https://github.com/VCVRack/VCV-Prototype/issues/39
@caowasteland I think that cutting out features it is the way to go here. If someone creates a malicious script called free-moog-maths.lua someone is going to run it and complain that VCV Rack broke his/her computer, even when it’s recommended to not load random scripts from the internet. If an advanced user wants to fully use LuaJIT, he/she should consider making a plugin and not rely on VCV-Prototype.
In the Github issue I mentioned that I’m going to unload ffi by making it null (and also require). That way ffi cannot be used neither reloaded. If you have any recommendation on how to make the plugin safer please let us know in the github issue.
If someone creates a malicious script, how is VCV Rack responsible? Aren’t we already asking end users to believe in our shared objects? Aren’t the scripts far easier to audit? By metaphor, is Microsoft responsible for the existence of Bonzi Buddy? Is Forschner responsible if one of its knives is used in a murder? I think it folly to assume responsibility for all stupidity and evil in the world.
For what it’s worth, you’ll find it’s far harder to turn LuaJIT into a walled garden than you imagine. I hope I’ve made it clear I find the effort misguided; end users bear principle responsibility for the security of their computers. If the end user doesn’t want hostiles to program, he shouldn’t install a programming system.
I don’t think the problem is that someone writes a malicious script, it is the fact that the script will be embedded in the patch file. If you download a patchfile (and have VCV Prototype installed) you don’t expect to be a victim of some misbehaving Lua-script…
1 Like
That’s certainly a very reasonable position; while patch files are JSON, few will audit them.
Nevertheless, folk might want to read what Mike Pall has said in regards to security once FFI has been loaded. I’ve spent serious time messing with setfenv trying to block FFI access, and I’m not convinced I didn’t leave holes big enough to drive a truck through. Lua sandboxes are very hard to get right.
My complaint primarily comes from wanting to be able to use any LuaJIT assets (scripts, extension libraries) I’ve created prior to my work with VCV, so I don’t appreciate the lobotomy.
Subject: … with VCV-Prototype installed.
I’m not sure if this also applies to the WrongPeople Lua module as well. I should test. Yup. It doesn’t stash the script, but it does stash the script’s path. (Maybe worse)
Vortico, thanks for the move. I didn’t mean it as a hijack, but that the general notion of library availability in LuaJIT had been broached.
VCV Rack users can download arbitrary .vcv patches on the internet and load them. It would be bad PR for VCV if malware was discovered to be distributed this way. It would be especially bad PR if the attack vector was a product with the VCV name, like “VCV Prototype”. It wouldn’t be less bad PR for a non-VCV product such as “WrongPeople Lua”, but because it’s distributed on the VCV Library for VCV Rack, it can still seem like VCV is somewhat responsible.
Because there may still be vulnerabilities in Prototype’s ScriptEngines, the user is prompted with a message like the following when loading a patch, if the script path doesn’t exist on the filesystem.
1 Like