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

Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Suggestions
. . -> [Subject]  Launching external programs, Lua security, etc.
Launching external programs, Lua security, etc.

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

Posted by Ked   Russia  (524 posts)  [Biography] bio
Date Wed 19 Jan 2005 09:05 AM (UTC)
Message
Okay, so I've been meaning for a long time to rewrite my old StatusGauge program so that it becomes more stable and works out of the box. The recent surfacing of Lua as a "truely embedded" scripting language, the UDP callbacks, and the window positioning callbacks all combined to make it worth the while to look at the StatusGauge code again. Since I don't have to use COM, stability improves by an order of magnitude, since I can get the window positions for Mushclient, I can think of some scheme of docking StatusGauge, since I can use Lua, I can package StatusGauge into an executable and the users won't even need to have vbs installed on their system to make its controlling plugin work, etc.

However, there are still a couple of concerns. Firstly, the problem with launching StatusGauge. Before, I could easily do it through COM, since that automagically gets all the needed data from registry. Now I have to shell execute the program manually, and to do that I need to know where the program is on the disk. Using some installer I can more or less easily record the program's path in the registry, but I can't use Lua to later read that path from the plugin. This leaves me with requiring the user to install the program in some subfolder in Mushclient's directory, which isn't too big of a problem either, but I still don't like that idea for some reason. Besides, I am not sure, but I don't think there's even a way to find out Mushclient's own path from a script, which means that the user would have to manually tweak the plugin code to set the path. Maybe a callback to read the registry could be added to make fully automated custom installs of 3rd party software really possible. Along with a callback to get the path to Mushclient's main directory, without needing to know the registry key where that sits.

Secondly, the Lua sandbox. I agree that it improves the safety and is a great idea overall, but I think that it could use some further improvements. Namely, since it is already possible to set up separate sandboxes for individual plugins, maybe there should be a way to automate the process for the user. Something along the lines of how web browsers install additional software, where you get a popup window asking you whether you want to allow this program to install. The plugin author could request access to certain os and io methods from OnPluginInstall, providing a short description of why such access is needed, and the user would be prompted for confirmation on each request:


function OnPluginInstall()
   RequestSandboxPermission ("os. execute", "Needed to launch StatusGauge.exe graphical display component.")
end


Resulting in the user seeing something like:

Plugin "StatusGauge" (id: xxxxxxxxxxxxx) requests access to the os.execute method. Reason:

Needed to launch StatusGauge.exe graphical display component.

Author: Xxxxx
Date written: xx-xx-xxxx
Purpose: xxxx xxxx

If you answer Yes, this method will be enabled only for this plugin.

Click Yes to grant permission, No to refuse.

Yes No

[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #1 on Wed 19 Jan 2005 05:34 PM (UTC)
Message
On the other hand.. There is nothing preventing you from making an ActiveX whose only capabilities are allowing you to load the application as an object and maybe 'version'. Or some people are looking at ways to use the free wxWindows and wxLua interfaces (which are also cross platform) to create their programs instead.

But, if nothing else you can always find an installer that can read/find mushclient's installed location and install directly in the right place. There may be a lot of other options, even including adding a registry key when installing the program that Lua could look at to find it, etc.
[Go to top] top
Posted by Faux   United Kingdom  (77 posts)  [Biography] bio
Date Reply #2 on Wed 19 Jan 2005 11:30 PM (UTC)
Message
I'm just going to show some support to the wxLua way of doing things, but it still doesn't get around the sandbox.

Another possiblility is playing with LuaCOM, which allows you to do anything you could have done with that kind of stuff in vb (afaik).

I'd really like to see support for at least one of wxLua and LuaCom in MUSH.. I don't know how far away that is.

Quote:
..Mushclient's main directory..


GetInfo() allows you to get things like that.
http://www.gammon.com.au/scripts/function.php?name=GetInfo
Faux, from Discworld. Feel free to come talk to me =)

http://faux.servebeer.com/
[Go to top] top
Posted by Ked   Russia  (524 posts)  [Biography] bio
Date Reply #3 on Thu 20 Jan 2005 03:27 AM (UTC)
Message
Quote:
There is nothing preventing you from making an ActiveX whose only capabilities are allowing you to load the application as an object and maybe 'version'.


I haven't thought of using ActiveX just to launch the application, but it might work. I'll look into it. Though ActiveX means the need to include pywin32 package into the executable, which was one of the things I am trying to avoid in order to decrease its final size. As for reading the registry from Lua, do you know if there are any methods for doing that (without needing external libraries)?

Quote:
I'm just going to show some support to the wxLua way of doing things, but it still doesn't get around the sandbox.

Another possiblility is playing with LuaCOM, which allows you to do anything you could have done with that kind of stuff in vb (afaik).


I've tried looking at wxLua to see if it could provide something I didn't already have in Python. But to say the truth - it didn't. It's not very stable yet, as you've said yourself elsewhere. It also makes a hefty download for the user, with the wxLua.dll needing to be included. Basically, what I have now is almost exactly the same thing as what you did with your status bar - only with wxPython instead of wxLua, and pywin32 (win32com part of it) instead of LuaCOM. So there's not much sense in changing horses.

Then, again, you bump into the sandbox when trying to run it in Lua, which means manually tweaking the initialization script. The sandbox is the main concern really - even though one could probably do without the registry callbacks, the sandbox definitely needs some tweaking to allow the users to more easily customize it through the GUI and change the permissions during program's runtime. If nothing else, the "permission windows" I mentioned above would look "cool", and might add a level of "sophistication" to Mushclient even if that level would be purely superficious: people still judge products based on subjective feelings :P
[Go to top] top
Posted by Faux   United Kingdom  (77 posts)  [Biography] bio
Date Reply #4 on Thu 20 Jan 2005 12:17 PM (UTC)
Message
Ah, sorry Ked.

I read your post as if you were using VBScript.

Quote:
As for reading the registry from Lua, do you know if there are any methods for doing that (without needing external libraries)?


Without even looking, I'd say that there is no chance of this, simply due to the size and portablity of Lua.
Faux, from Discworld. Feel free to come talk to me =)

http://faux.servebeer.com/
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #5 on Thu 20 Jan 2005 06:52 PM (UTC)
Message
Yes. You will absolutely and certainly need to write some C functions that use the Win32 API, that in turn will interface to Lua via the Lua C API.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #6 on Sat 22 Jan 2005 09:54 PM (UTC)
Message
Quote:

Besides, I am not sure, but I don't think there's even a way to find out Mushclient's own path from a script ...


GetInfo (56)

Quote:

Secondly, the Lua sandbox. I agree that it improves the safety and is a great idea overall, but I think that it could use some further improvements ...


I suppose, but the idea of the sandbox was to stop plugins doing things like: os.execute ("del \winnt\kernel.dll") or whatever a nasty command would be.

To allow plugins authors to active os.execute "so the plugin will work" basically gives them a simple tool to circumvent the safety.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #7 on Sat 22 Jan 2005 10:27 PM (UTC)
Message
That's why it would be up to the users to decide whether or not to trust the plugin author. Surely you agree that in some cases a plugin would need things that have been removed in the sandbox?
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Ked   Russia  (524 posts)  [Biography] bio
Date Reply #8 on Sun 23 Jan 2005 05:32 PM (UTC)
Message
Quote:
To allow plugins authors to active os.execute "so the plugin will work" basically gives them a simple tool to circumvent the safety.


No, no, no, I am not saying: provide a way to active os.execute. What I actually mean is: simplify for the user the procedure for allowing the plugin to active os.execute. The user would still have to give his/her permission for the plugin to get access to the function. This would arguably be safer also, since if I really wanted to be trendy and write a plugin in Lua, and needed "loadlib" for example, I would be very likely to just skip all the trouble and recommend the users to comment out the MakeSandbox() line in the init script. Which would be really awful, but such is the nature of human laziness :P So an easy way to enable a specific method for a specific plugin (as opposed to all methods for everyone) might improve security, as opposed to worsening it.
[Go to top] top
Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #9 on Tue 25 Jan 2005 02:57 AM (UTC)
Message
I understand what you want. What I am saying is that it would be easy to write a Trojan Horse style plugin that claims to do all sorts of fantastic things "if only you enable os.execute for me".

It would be a human-engineering attack, convincing a naiive user to enable it.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #10 on Tue 25 Jan 2005 06:57 AM (UTC)
Message
Well, that's a problem whenever you run software. Ultimately it's always up to the user to decide whether or not to trust somebody with an executable.

My vote would be to ask people multiple times if they're really sure they want to allow certain functions. I think it would be sufficient to state that they do so at their own risk, that the plugin might be malicious, and leave it at that. Frankly I don't think it's your problem if somebody downloads, installs and authorizes a malicious problem. Can't protect everybody from everything, after all. :-)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #11 on Wed 26 Jan 2005 01:22 AM (UTC)
Message
Well, frankly that is what Microsoft did until howls of protest are gradually forcing them to change.

It is a trade-off between convenience and security, you simply can't have both. For example, Microsoft argue that if you get a malicious email attachment and execute it, that isn't their problem, you shouldn't have done it. However they made it simple enough to do with one click.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #12 on Wed 26 Jan 2005 04:06 AM (UTC)
Message
But only after first also making sure everyone using outlook was a clueless drone that didn't know it was dangerous. They simplified things to the point where the average person can hang themselves by the mere act of turning on the power switch. Not sure providing something like maybe showing the effending line and telling them to make 'really sure' it wasn't something bad before allowing it would do way more than MS ever even tried to educate people about what is really going on.
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #13 on Wed 26 Jan 2005 04:52 AM (UTC)
Message
IMHO the security you're talking about is an OS-level thing, not an application level thing. Even on Unix if you run a malicious program it can wipe out all your personal files or other nasty things. That it can't wipe out the kernel is inherent to how Unix is built; on Windows you have some degree of security but not nearly enough.

What would you have Microsoft do? Make it require four clicks to open an attachment? :) That'd be incredibly annoying to all the rest of us.

In any case, the other languages aren't sandboxed, right? So what prevents somebody from doing something potentially malicious there?

Here's the real problem. Some plugins will need extra features and so people will be tempted to just stop sandboxing entirely. But at that point, they have no security against any plugin. But with the system being proposed here, where you authorize plugins on a per-plugin basis, you're only lowering your defenses against one at a time - and presumably, this *one* plugin is something you trust and do have to explicitly authorize.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Ked   Russia  (524 posts)  [Biography] bio
Date Reply #14 on Wed 26 Jan 2005 06:00 PM (UTC)
Message
Quote:
For example, Microsoft argue that if you get a malicious email attachment and execute it, that isn't their problem, you shouldn't have done it. However they made it simple enough to do with one click.


But there's a big difference there: you are not letting the user launch a script, the user decided to launch the script when he downloaded and installed it on his computer. You are merely warning the user to the fact that the script that he is trying to install is asking for certain functions that could possibly compromise the system security. As I said before, this is actually better for security, given the existing situation with scripting languages. Instead of prompting whoever would want to write a malicious plugin to use the notorious vbs and do everything silently, or (if he is so inclined to do it in Lua) to "social engineer" the user into completely dropping the safety net by removing the sandbox, you are prompting those who wish to write plugins that access the file system or load arbitrary libraries (but with no ill intent) to warn the user explicitely of their actions and give him the right to choose whether he wants to trust this particular author or not.
[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.

37,686 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 HostDash]