approved custom scripts
Racer1
Join Date: 2002-11-22 Member: 9615Members
Join Date: 2002-11-22 Member: 9615Members
I'd like to see NS2 implement a method to allow custom scripts (on the client and/or server) to be evaluated. This process could approve scripts for use in "pure" or "modded" servers, provided they follow the guidelines specified by UW.
The guidelines to approve scripts for "pure" servers would be much more strict than those for "modded" servers. Servers that wish to allow
unapproved scripts could do so, but would be marked as "free" mode servers.
The evaluation process:
A script author who wishes to have their script approved would generate a key for the script file(s) -- possibly a SHA hash of the uncommented code. They would then submit the script to the evaluation team. The team would then determine if the script follows the guidelines for "pure" mode, for "modded" mode, or does not follow the guidelines (and would not be approved).
If approved, the status of that script would be made available on a UW server. NS2 servers could then authenticate any scripts and validate them to the approved list, if desired.
- The evaluation would be done by UW and/or a trusted team from the community.
- Players would be able to optionally choose from servers running in "pure", "modded", or "free" mode.
- If an approved script is later found to be breaking the guidelines, it could be removed from the approved list.
- Specific guidelines for "pure" and "modded" mode could be determined in the future. However, I would expect that "pure" mode scripts could not change gameplay, but allow enhanced features, custom menus (like voting), or fix annoyances. "Modded" mode scripts could modify gameplay substantially, but would not be allowed to collect personal data or be unstable.
The guidelines to approve scripts for "pure" servers would be much more strict than those for "modded" servers. Servers that wish to allow
unapproved scripts could do so, but would be marked as "free" mode servers.
The evaluation process:
A script author who wishes to have their script approved would generate a key for the script file(s) -- possibly a SHA hash of the uncommented code. They would then submit the script to the evaluation team. The team would then determine if the script follows the guidelines for "pure" mode, for "modded" mode, or does not follow the guidelines (and would not be approved).
If approved, the status of that script would be made available on a UW server. NS2 servers could then authenticate any scripts and validate them to the approved list, if desired.
- The evaluation would be done by UW and/or a trusted team from the community.
- Players would be able to optionally choose from servers running in "pure", "modded", or "free" mode.
- If an approved script is later found to be breaking the guidelines, it could be removed from the approved list.
- Specific guidelines for "pure" and "modded" mode could be determined in the future. However, I would expect that "pure" mode scripts could not change gameplay, but allow enhanced features, custom menus (like voting), or fix annoyances. "Modded" mode scripts could modify gameplay substantially, but would not be allowed to collect personal data or be unstable.
Comments
However, your proposition only covers the area of modifications based upon the alteration (or addition) of Lua-scripts. I have been contemplating the security risks that DLL-plugins pertain, and have considered the idea of code-scrutiny (similar to what you are suggesting for Lua-scripts) unviable when it comes to programming languages of the calibre of C or C++. If not for the sheer amount of time required to determine the threat a code poses (if indeed you can guarantee safe code when it comes to C\C++, just have a look at some of the wonderful obfuscation-contests held for these languages), then because of the undesirable idea of having to lay out every piece of code required to compilate a project (which can extend far beyond just the code specific to that mod).
At the moment, the only answer I have to this particular problem, is to extensively test such a mod, and otherwise trust it's author. While we're on this topic, I would also like to suggest the NS2 dev-team to introduce a hash-check function in the NS2 Lua-library, to allow for running file-checksums on specific files (DLLs in this case) in an otherwise sealed sandbox. I ask this because it is possible (for a person with the capabilities), to replace the DLL that a Lua-script might call, for one of his own making, and effectively take over the entire game. This would only be possible on that person's client as the server does not sync DLLs (as far as I'm aware, and at the moment I don't think it is wise to do so in the future), but it would still allow him to manufacture advantages that could be as extreme as complete aimbots (I'm uncertain exactly how much information the server sends to the client, but I believe it includes precise position-information of other players close enough to him).
Allowing custom DLLs to be loaded and used at will by Lua in this case would definitely be a large error on the part of the developers. A single DLL can allow for arbitrary IO and given that Spark has (or will have... hopefully) sockets usable by Lua, it would be pretty easy to to take over a system. I don't think many people in the community would think about doing such a thing, but all it takes is one person to really make peoples lives a living hell.
<!--QuoteBegin-"Racer1"+--><div class='quotetop'>QUOTE ("Racer1")</div><div class='quotemain'><!--QuoteEBegin-->stuff<!--QuoteEnd--></div><!--QuoteEEnd-->
I don't really think a server validation system is required in this case... at least not now. Sparks Lua implementation uses some pretty simple API calls which could, in theory, allow a script to be easily categorized as 'Pure' or 'Gameplay Changing Script.' For example, writing or reading gameplay information like player health would flag the script as 'Gameplay changing' because regardless of whether the player health is read or written to, it can be used to drastically change the gameplay from NS2's original intent.
Unreal Tournament sported a whitelist, client/server validation system as well. I'm not entirely sure how it worked as far as hash validation or no hash validation, but I'm fairly certain it wasn't an automated process either. There weren't many things on the list and I believe you sent in your code and compiled script for someone to be evaluated somehow. I think this could be an automated process however, where only the API calls are validated (all other code is useless), and a server can look for certain API calls/Values accessed.
Any small modifications you want to do shoud be done as a mod by copying the scripts you want to alter over to "mymod" and launching the server with -game mymod as well as the clients doing the same.
The original plans, not exected yet was to give indication of servers running large or small conversions, prompting the users if they would like to download and connect including having game filters so you can easily decifer between modded and venilla.
We will have to see what the future brings on this side of development for mods. Too early at the moment.
Reasons:
Admin mods should be allowed
Mods purely for logging (chat/reporting/other) should be allowed
Mapcyclers should be allowed
Pretty much any mod that is not changing the actuall gameplay, but makes administration easyer/better.
I would have to strongly disagree with your statement about the mistake of including a DLL-plugin mechanism (if only because I have a couple of exciting mods in the works that will be rendered useless without it). Although you are correct that malicious DLLs can inflict damage, I believe that with sufficient scrutiny by the community, a number of these mods can make it into the real-world and improve the game because of it. It should be noted by the way, that during development I have noticed that DLLs loaded by Lua are constricted somewhat, in a particular case it involved a DLL connecting to the Windows debugging-system to catch messages coming from the Logitech-gamepanel, in order to allow users to customize their G-keys for specific NS2-actions, which I didn't get working simply because the DLL did not have the appropriate access-rights. Another example is the loading of an external module (DLL or executable) by the DLL, which I have found not to be possible. Perhaps this is because the NS2 dev-team has considered this security-risk and curtailed various of the DLL's rights. Thus I think things are not as grim as you might think. Though just in case, perhaps I should send a PM to a dev-team member to inquire about the future of this plugin-system (I'd hate to invest time into something that'll disappear at some point).
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->I don't really think a server validation system is required in this case... at least not now. Sparks Lua implementation uses some pretty simple API calls which could, in theory, allow a script to be easily categorized as 'Pure' or 'Gameplay Changing Script.' For example, writing or reading gameplay information like player health would flag the script as 'Gameplay changing' because regardless of whether the player health is read or written to, it can be used to drastically change the gameplay from NS2's original intent<!--QuoteEnd--></div><!--QuoteEEnd-->
I too considered this. Something along the lines of a const-correctness (C\C++) system, that would flag a variable whenever a mod attempts to call a function that is not (const).
DLLs will definitely allow for some fun things, but most of my concern isn't really from this Community, but from the Internet in general. Maybe this is a conversation for another thread but consider the following:
If you released ModX that would scan your hard drive for file names and somehow create monsters in the game based on them, it would likely be well received and enjoyed. Your intentions are sincere, and all others in this community have put their Stamp of Approval on it both in Security and Fun factor. For our intents and purposes we might even go so far as to say the DLL is impervious to external attacks. So far so good.
This is this community though. The Internet, as everyone knows, if full of evil, evil people. One such evil person takes your mod, and because Lua has a standard interface for DLLs, he swaps out your DLL with his own. He makes some modifications to your code so the right functions are called and now he has a DLL that not only scans your hard drive but also deletes files as well. Now, I could be very wrong, but I don't think there is much you can do to sandbox a DLL. So BadGuyX releases your mod on forum X,Y and Z, lesser know forums and from there gets spread to FilePlanet and various other sites - all the while he makes no claims that he is the Author and instead gives Kudos to you for making such an awesome mod.
Etc, Etc...
There are a couple alternatives you can use to work-around such things. For example, a game I played frequently had many asteroids you could mine but no way to keep track of it. Through a scripting interface, you could make your own database of sorts, but saving data was limited to an INI file which was occasionally purged so it wasn't very reliable. The scripting community for this game was fairly large and I found that because this game had a usable socket via the scripting interface, you were able to connect to arbitrary web pages.
I therefore set-up a local Database and along with server-side web pages was able to save and retrieve asteroid data to and from the game. It was a very round-a-bout way but it got the job done and was very cool. You could consider doing the same when a socket is usable (it might already be, I haven't delved into the NS2 API at all yet). Instead of a web page, you might just directly connect to a "server" that simply sends information to and from your Keyboard.
<!--quoteo(post=0:date=:name=player)--><div class='quotetop'>QUOTE (player)</div><div class='quotemain'><!--quotec-->I too considered this. Something along the lines of a const-correctness (C\C++) system, that would flag a variable whenever a mod attempts to call a function that is not (const).<!--QuoteEnd--></div><!--QuoteEEnd-->
You could probably implement this in Lua as well without too much overhead. Might even be easier. *shrug*
It is an interesting point you're making, and I think the most relevant one. It is because of this reason I suggested a hashcheck-function to be available for Lua-scripts to verify an external DLL (or other peripherals) for it's integrity. This way a supplied DLL cannot be replaced or modified. If it is, the script will pick up on it and refuse function. This places the unsuspecting user in the clear, because the Lua-scripts (among other things) are synced from the server, thus the checksum of a DLL cannot be changed client-side, as the server will simple overwrite it with the correct one. Thus the responsibility is moved to the server-operators (which we can agree on, can be considered more competent and vigilant than the average player). But even server-operators can become victims of a scam like you are describing, so, to return to the original topic, I would indeed agree with the suggestion that mods are indexed and classified. With mods that contain DLL-loading routines to be subjected to intense scrutiny. When all the NS2-mods are nicely categorized on the main site, it will help aliviate the problem you are describing.
So, in summary, an extensive database of mods available for NS2, evaluated or otherwise, with an in-depth description on what they do, and the risks involved, would be a good idea. This goes double for mods that make use of DLLs. And of course that hashcheck-function I talked about earlier, which is absolutely vital when it comes to the use of client-side DLLs.
Just the sheer amount of work to go through things like this requires a whole new job that the devs don't have yet.
Any volunteers?
Or better yet, someone want to start up their own modding site + staff + database?
=p
If UW lays the groundwork, then I think that players WOULD accept the task. However if UW fails to do this, then any potential effort is at best a 3rd party tool that everybody has to install to play NS2...and at worst a nightmare of multiple groups of players pushing their own approval servers hosted from uncontrolled systems. Given these outcomes, the potential for failure makes the motivation for doing the work mediocre at best.
So, I'd like to see UW do the following (not all of these necessarily have to happen):
1. Say that they would like to set up a script approval system, and would support attempts to do so. (This alone would stir enough interest to get something started).
2. Provide an official method to package 3rd party scripts and generate a key (like an SHA hash) for those scripts.
3. Create a tiered approval convention (e.g. "Pure", "Modded", "SomethingElse", "Unapproved") with minimum guidelines at each level.
4. Create a simple API for determining the approval level of scripts. Then ask NS2 fans to write their own implementation and submit it for inclusion in NS2 after an evaluation process.
The process could go a few directions from there, but would be a good start.