Eat_My_Shortz wrote:

Quote:

MOUL uses a custom interpreter, so the situation is somewhat easier than trying to harden the stock Python interpreter.

What? Cyan wrote their own Python interpreter?? Surely this isn't true... it would take a huge effort to write a working Python implementation (I know because a friend of mine has done it).

No, they customised CPython. It's the same language, but with only a minimal set of built-in classes and functions. Also, individual scripts are executed in separate sub-interpreters. This makes it easier than trying to harden the stock Python distribution (i.e. it might actually be feasible, whereas hardening stock Python has been tried repeatedly, and has failed repeatedly).

Quote:

Quote:

Quote:

The only way to guard against malicious Python scripts is to hand-inspect them before letting them go out to clients.

Which would largely defeat the point of open-source.

No it wouldn't... you would still be able to see the source code, modify it for your own purposes, if you have a useful patch send it upstream so it can be used by servers and clients. This would apply to the game code as well as custom ages. It would then be up to the server to choose whether to support your particular custom Age, just as it's up to them whether to support your particular custom code.

Then the server admins have to make a decision whether to accept your code, and the user has to make a decision as to whether or not to trust a particular server. Server administrators aren't necessarily programmers (and not all programmers can perform a security audit), and users aren't really in a position to make an informed decision about the safety of a server.

The client and server need to be able to safely handle whatever code gets thrown at them.

Quote:

In Ubuntu, it isn't the case that just anybody can get code in the official repositories (becoming part of the operating system). There is a strict vetting process. That doesn't mean that Ubuntu "largely defeats the point of open source."

The situation is different for "mobile" code which is downloaded and executed without user intervention, and needs to handle untrusted data. If age scripts have to be manually vetted, that's going to maintain a "walled garden" environment, which will be a significant limitation.

Keikoku wrote:

No, they customised CPython. It's the same language, but with only a minimal set of built-in classes and functions.

I really don't think that Cyan modified any part of the core interpreter; I think that the Python DLL that comes with Uru is stock (though this is still guesswork since we don't have the source). What they did do, however, is leave out most of the standard modules. These modules are mostly implementation independent, and are not considered part of CPython (I beleive).

Eat_My_Shortz, Uru can be a much more interesting (and open) place if ages can be downloaded and explored without the need for a central vetting process or even a security review from the explorer. Having each age checked out before release will work well for now, with basically one Cyan-run server and one data source with few age creators. However, if we want a future with many age creators and many data sources, a secured python would be a good thing to have.

(This thread has been enlightening. I've never thought so much about how to secure a python interpreter before, or how to prevent greifers in a loose, open-source MMO. These are interesting problems!)

In ABM, UU, and PotS there is a Python 2.2 dll in the Uru directory, containing the standard runtime.

In Myst V, Hex Isle, and MOUL, the Python 2.3 runtime is embedded in the main .exe, which means that itmay have been edited for security.

As soon as Plasma is open-sourced, I suggest we upgrade to a recent version of Python such as 2.6 or 3.1

agrif wrote:

Keikoku wrote:

No, they customised CPython. It's the same language, but with only a minimal set of built-in classes and functions.

I really don't think that Cyan modified any part of the core interpreter; I think that the Python DLL that comes with Uru is stock (though this is still guesswork since we don't have the source). What they did do, however, is leave out most of the standard modules. These modules are mostly implementation independent, and are not considered part of CPython (I beleive).

The DLL doesn't have any obvious modifications. However, even without modifying the DLL, it's still possible to "patch" the execution environment before any external code is executed. Even with no additional modules, you would need to remove file(), open(), execfile(), etc for security.

People concerned about how to safely run untrusted python code should take a look at http://codespeak.net/pypy/dist/pypy/doc/sandbox.html. It describes a way to automatically generate a python interpreter that is incapable of communicating over a network, writing files, or any other sort of I/O except for reading from stdin and writing to stdout. Any untrusted python code (i.e. code bundled with an age) gets run in this sandboxed python interpreter, and all the file I/O and networking are handled on it's behalf by another program that acts as a gatekeeper. This controller program is responsible for implementing any security restrictions, so if the sandboxed python asks the controller to write a file in an unapproved location, it would simply refuse. The controller would be part of Uru, so it would be code that users got from a trusted source. As long as it's security policies aren't too permissive, the most that clients would be risking by running untrusted code bundled with an age is that the age would break, resulting in a crash to the desktop or linking to relto.

Of course, the above only solves the original problem of allowing the client to run untrusted python code. It doesn't solve any of the problems like flymode, but it does mean that we can make an Uru client that you can trust to never infect or destroy your system (provided you get an un-tampered Uru client from a trusted source).

Consider this a devil's advocate post from an open source believer (and promoter):

For your consideration:

Open-Source Could Mean an Open Door for "Hackers" [quotations added for subjectivity of the word]
http://www.technologyreview.com/computing/25480/

_________________
OpenUru.org: An Uru Project Resource Site : Twitter : Perfect Speed Is Being There.

The present configuration is an open door for "hackers" already, so I'm not too concerned

_________________
-Whilyam

My view is that if we use one central place to get patches from through the patcher we could have a PGP signing system, basically the GoMa and GoW could both have a private PGP key and only if a file or whatever is signed with that key (which we can check with the public key) it's valid. This also takes away the need for checksum stuff.

You could still have people manually installing untested/dangerous things but then manually installing things will become something you don't regularly do so people won't be stupid enough to do such a thing I guess.

Bert_2 wrote:

My view is that if we use one central place to get patches from through the patcher we could have a PGP signing system, basically the GoMa and GoW could both have a private PGP key and only if a file or whatever is signed with that key (which we can check with the public key) it's valid. This also takes away the need for checksum stuff.

You could still have people manually installing untested/dangerous things but then manually installing things will become something you don't regularly do so people won't be stupid enough to do such a thing I guess.

That doesn't do anything about the fact that the server trusts the client to behave, which is a fundamental design flaw (and, incidentally, one which is far more common with proprietary software; with open-source software, it's obvious that it won't work; with closed software, it's easier to convince yourself that people won't figure it out).

Right now, it's not much of an issue. MOUL is sufficiently obscure that few people will bother to analyse the binary. Those that have done so are basically committed fans and don't have malicious intent. If MOUL was popular, "hacking" it would be worth the effort. If the source code is released, it won't require any effort. But at the moment, it's too much effort for not enough reward.

My biggest concern with all of this is that Cyan won't release the source "until" the security issues have been fixed, which will probably translate into MOUL never becoming open source. Once you abandon proper client-server security in favour of trusting the client, it tends to fundamentally taint the design. Recovering from this takes a lot of effort, possibly more than Cyan can afford.

If there's a reason why the community would want to branch the Uru server/client code then how about creating a compile farm where the developers can submit their sourcecode and the compile farm can create the binaries for the client/server. That way anyone who is downloading a game client knows that the sourcecode is also available on the compile farm's webserver and in no way can the developer alter the code after it has been compiled by the server farm to remove any malicious code. In addition, if you're afraid that the developer could later change the server soucecode to include malicious code then what the server farm could do is after it reveals the source code on the web server, it could then inject authentication code into the source before compiling it so that the client could only connect to servers that have the correct authentication code which would have a public/private key pair as part of the encrypted binary. Hopefully that makes a little sense. If not, I can re clarify.

_________________
we6jbo | KI: 07869362
Debian - Asus P5B Delux motherboard - 3 GB Memory - 9800 GT 1024 GDDR3 PCIE2 - Intel Pentium 4 ES 2800 MHz