[Home] [Downloads] [Search] [Help/forum]

Gammon Forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Lua
. . -> [Subject]  reason for the sandbox and improvement ideas
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?

reason for the sandbox and improvement ideas

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page


Posted by Tspivey   Canada  (53 posts)  [Biography] 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.
[Go to top] top

Posted by Larkin   (278 posts)  [Biography] 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.
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] 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
[Go to top] top

Posted by Twisol   USA  (2,257 posts)  [Biography] 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
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] 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
[Go to top] top

Posted by Twisol   USA  (2,257 posts)  [Biography] 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
[Go to top] top

Posted by Tspivey   Canada  (53 posts)  [Biography] 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.
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] 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
[Go to top] top

Posted by Twisol   USA  (2,257 posts)  [Biography] 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
[Go to top] 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.


6,573 views.

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at FutureQuest]