reason for the sandbox and improvement ideas

I don't really understand the concept of trusted worlds and trusted plugins. Can you explain this?
What I've been able to understand so far:
* if a world is untrusted, trusted plugins will load as untrusted. Why?
If I trust a plugin, it should load as trusted.

* if a world is trusted, untrusted plugins will load into it. Does a trusted world in this context mean
a world whose scripts (and plugins) are trusted by the user, in which case should we just load the plugins as trusted?

If the sandbox is needed, these ideas might help make it a bit more secure:

1. Disable DatabaseOpen in the sandbox.

2. Intercept LoadPlugin(), parse the file with utils.xmlread and ensure that its language is lua. That would do nothing
against manually installing something that wasn't, though.

I just find it odd that the sandbox is there for lua, when the other languages can be more easily used for malicious purposes if so desired.

The other languages are probably more difficult to sandbox, as they're not as tightly coupled with MUSHclient. The Lua sandbox is just a nice security measure to keep third party scripts and plugins from trashing your computer. (I doubt anyone's ever written such malicious code and distributed it, but one never knows.)

My own scripts use file I/O, and I distribute them to a lot of people (not as plugins, either), so I have to instruct everyone on how to edit their sandbox in order for my scripts to function properly on their installations. Bit of a hassle, but only has to be done once.

You are probably right about that. I suppose when I wrote that, my first thought was that if the world was untrusted, straight away scripts should not be trusted.




No, it means that the creator of the world (probably the player at the keyboard) trusts his own code, but doesn't trust plugins s/he downloaded from the Internet.




Once again it is a tradeoff between having convenience for the player, and security. I thought opening a database was reasonably secure, but that could probably be abused, yes.

I'm not sure if your overall post is arguing for tighter controls or looser ones.

Personally, I think the security model itself is a bit flawed. For example, I'd rather see script operations on the file system limited to only the MUSHclient directory, at most.

But this is very difficult to control without doing a whole lot of (error-prone) work to wrap all of the scripting language's IO functions.

It'd be easier to give APIs that access "MUSHclient data files" without actually giving paths etc., rather than trying to have normal IO but only to a special directory.


EDIT: also I'm not sure why this level of security is needed in the first place? Plugins are open-source, so it's not like you can't check them out before using them. And ye average user, who doesn't read code, isn't necessarily going to know to deal with the security settings in the first place, either.

I was talking mostly about the MUSHclient API itself, not the scripting language's libraries. SaveNotepad(), DatabaseOpen(), etc etc.


I pointed this out to someone else recently, actually. On a related note, I'd prefer that MUSHclient treat worlds more as "profiles" than as "world files", and have the script file as part of the world file itself (and editable from the configuration menus). But that's another topic altogether.



I suggested a "plugin permissions" option/dialog a while back, to make it as easy as checking a checkbox. Much easier than reading code, and easy to add instructions to do.

I vote for getting rid of the sandbox, and the allow dlls checkbox. My reasoning being that
if someone really wanted to write a malicious plugin for MUSHClient, the other *script languages would
be an easier place to start.

But this doesn't really solve the security problem. Non-coders still won't read source code, so they still won't really know if the plugin is clean or not. In the end of the day, based on empirical experience from all sorts of people in many parts of the computer world, people will just download and immediately "trust" plugins if they have to. So this really isn't doing anything.

Again, though, what is the higher-level problem we're trying to solve here? Are we trying to prevent people from slipping in malicious plugins? Well, can't people slip in any number of malicious programs with far easier vectors than MUSHclient plugins? It just seems to me that this is trying to do more than is really within our control to do.

After all plugins don't just show up on the user's computer, they still need to go download the plugin, install it, etc. So it's not like other users can run arbitrary code unless you install the plugin deliberately. (This is also why the checkbox-trust method doesn't really work: it's just adding another step for people to blindly check a box to say they "trust" the plugin even though they really don't.)

Think of Firefox extensions: is there any trust mechanism there? Nope-- not beyond a box saying "are you sure you want to install this?". However one major difference is that Firefox plugins undergo even a nominal peer review.

Again though it seems like this is trying to solve a problem that we don't really have, or that we can't really solve anyhow.

I could care less about the security, since it has so many holes at it is. I just want my users to be able to use my advanced plugins without digging through the sandbox code. You said it yourself: "non-coders still won't read source code", nor should they have to. When I made that dialog suggestion, I was just going on the assumption that Nick wanted to keep his security system.