Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Entire forum
➜ MUSHclient
➜ Lua
➜ reason for the sandbox and improvement ideas
reason for the sandbox and improvement ideas
|
Posting of new messages is disabled at present.
Refresh page
Posted by
| Tspivey
Canada (54 posts) Bio
|
Date
| Wed 07 Apr 2010 09:47 AM (UTC) |
Message
| 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. | Top |
|
Posted by
| Larkin
(278 posts) Bio
|
Date
| Reply #1 on Wed 07 Apr 2010 02:28 PM (UTC) |
Message
| 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. | Top |
|
Posted by
| Nick Gammon
Australia (23,122 posts) Bio
Forum Administrator |
Date
| Reply #2 on Thu 08 Apr 2010 01:03 AM (UTC) |
Message
|
Tspivey said:
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?
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.
Tspivey said:
* 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?
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.
Tspivey said:
If the sandbox is needed, these ideas might help make it a bit more secure:
1. Disable DatabaseOpen in the sandbox.
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. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Twisol
USA (2,257 posts) Bio
|
Date
| Reply #3 on Thu 08 Apr 2010 01:32 AM (UTC) |
Message
| 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. |
'Soludra' on Achaea
Blog: http://jonathan.com/
GitHub: http://github.com/Twisol | Top |
|
Posted by
| David Haley
USA (3,881 posts) Bio
|
Date
| Reply #4 on Thu 08 Apr 2010 02:11 AM (UTC) Amended on Thu 08 Apr 2010 02:12 AM (UTC) by David Haley
|
Message
|
Quote: 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. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | Top |
|
Posted by
| Twisol
USA (2,257 posts) Bio
|
Date
| Reply #5 on Thu 08 Apr 2010 02:19 AM (UTC) |
Message
|
David Haley said: 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.
I was talking mostly about the MUSHclient API itself, not the scripting language's libraries. SaveNotepad(), DatabaseOpen(), etc etc.
David Haley said: 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.
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.
David Haley said: 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 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. |
'Soludra' on Achaea
Blog: http://jonathan.com/
GitHub: http://github.com/Twisol | Top |
|
Posted by
| Tspivey
Canada (54 posts) Bio
|
Date
| Reply #6 on Thu 08 Apr 2010 03:26 AM (UTC) |
Message
| 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. | Top |
|
Posted by
| David Haley
USA (3,881 posts) Bio
|
Date
| Reply #7 on Thu 08 Apr 2010 04:05 AM (UTC) |
Message
|
Quote: I suggested a "plugin permissions" option/dialog a while back, to make it as easy as checking a checkbox.
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. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | Top |
|
Posted by
| Twisol
USA (2,257 posts) Bio
|
Date
| Reply #8 on Thu 08 Apr 2010 05:06 AM (UTC) Amended on Thu 08 Apr 2010 05:07 AM (UTC) by Twisol
|
Message
| 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. |
'Soludra' on Achaea
Blog: http://jonathan.com/
GitHub: http://github.com/Twisol | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
26,515 views.
Posting of new messages is disabled at present.
Refresh page
top