It is currently Tue Jul 16, 2019 10:38 am

All times are UTC




Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 100 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next
Author Message
 Post subject:
PostPosted: Sun Feb 21, 2010 7:00 pm 
Offline

Joined: Thu Aug 03, 2006 10:55 pm
Posts: 625
Agrif already mentioned this, but since no one seems to have commented, I'm going to re-iterate:

It is possible, through the Python C interface, to look at and modify any python data structure, including the list of global
functions and classes. You can use this to remove/modify all the dangerous calls. This has never been considered a "viable option" by the Python folks, but their working premise is "safely run any python script and let it run properly without damaging the system". Our premise is "make sure Uru Python scripts don't do anything not Uru-related". That gives us a lot more leeway to downright remove functions we think are dangerous.

Additionally, a lot of the dangerous stuff is in the Python standard library. This library is not installed with Uru. Developers and artists will by necessity have the full python library installed, but most users will have no reason to install it.

EDIT: I haven't done any python/c work in a while, but I can make a proof-of-concept of this if needed...


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Feb 21, 2010 9:56 pm 
Offline

Joined: Fri Feb 19, 2010 5:04 pm
Posts: 115
Location: England
PaladinOfKaos wrote:
It is possible, through the Python C interface, to look at and modify any python data structure, including the list of global functions and classes. You can use this to remove/modify all the dangerous calls.

It's not that simple. Python just loves leaving references lying around which could be exploited.

E.g. even if you remove the open() function and file() constructor from the global namespace, if you can get a reference to any file object, you can use type() to get a reference to the class, which is then usable as a constructor, e.g.:

Code:
import sys
myfile = type(sys.stdin)
f = myfile("foo.txt", "w")

There have been two serious attempts at restricted execution in Python: rexec and Bastion. And both of them have been removed from Python 3 because they never actually worked, insofar as it was always possible to find loopholes.

IMNSHO, there are only three ways to get restricted execution that actually works:

1. OS-level sandboxing, i.e. running scripts in a separate process using a ptrace-style sandbox. Highly platform-specific, and ultimately far too heavyweight.

2. Java. Restricted execution was a fundamental design goal from the outset, supported by enforced public/protected/private member access and SecurityManager classes. But it's still too heavyweight.

3. Languages such as JavaScript and Lua which were designed for embedding, rather than as general-purpose programming languages. Such languages have a minimal "core" in order to make the language as flexible and as easy to host as possible. Consequently, you don't have to worry about locking down all possible routes to dangerous functionality; you just don't provide such functionality in the first place.

Option #3 is by far the easiest to implement. I would expect it to be entirely adequate for scripting levels (in particular, Lua has been used for a few dozen commercial games).


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Feb 23, 2010 5:53 pm 
Offline
Obduction Backer

Joined: Wed May 31, 2006 4:09 am
Posts: 20
Keikoku wrote:
Option #3 is by far the easiest to implement. I would expect it to be entirely adequate for scripting levels (in particular, Lua has been used for a few dozen commercial games).


Moving to Lua is an excellent long term solution. It would fix all of the security issues we have with Python now. However, managing this migration would be tricky... Cyan's ages are likely to stay in Python for as long as they control them, and fan made ages already created or being created would have to be converted. Switching from Python to Lua would drive away those who had learned Python, expecting to be able to make an age, and now learn they can't.

You still end up with an issue of trust, even if only for Cyan ages. Age signing with, say, RSA, would be the best option, but as you mentioned, there are problems with exporting cryptography. I seem to remember that this is only an issue above a certain strength (key length), but I may be wrong, or maybe the keys would be too short to be useful.

I have only passing experience with the Python C API, but maybe there's a way to hook the 'open' call in C, at the source (sort of like belford said). You may even be able to replace the built-in file type. As far as I can tell, without the Python standard library, this is really the only major security concern. Everything else in the standard library can be edited out without having to use a custom branch of Python.

(I love that this community is knowledgeable enough about these topics to have a thorough discussion of security issues in an open source, fan created content Uru.)


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Feb 23, 2010 7:56 pm 
Offline

Joined: Fri Feb 19, 2010 5:04 pm
Posts: 115
Location: England
agrif wrote:
Cyan's ages are likely to stay in Python for as long as they control them, and fan made ages already created or being created would have to be converted. Switching from Python to Lua would drive away those who had learned Python, expecting to be able to make an age, and now learn they can't.

Given the overall amount of work in creating in age, I'm sceptical that someone would abandon their work over something so minor.

As I see it, it boils down to: Python, Open-Source, Security; pick any two.

Security isn't a problem if there's a central authority which can vet scripts (although I can't see Cyan performing that role for anyone's ages but their own). Or if ages are coming from a small number of trusted sources (and you actually know where the ages are coming from, i.e. if you have to explicitly download and install them first). But I'm looking towards a future where you can walk into a library containing shelf upon shelf of linking books, pick one at random and link there. In turn, those ages may have their own libraries of books; IOW, a "web" of ages.

Any kind of vetting system isn't going to scale to such a world, and if a player finds a new linking book, the last thing they are going to want to do is to stop playing and perform "due diligence" before linking.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Feb 23, 2010 8:52 pm 
Offline
Obduction Backer

Joined: Wed May 31, 2006 4:09 am
Posts: 20
I looked around at various Python sandboxing techniques, and found RestrictedPython. Now, I don't really know if this will do everything it needs to, but it looks like it might. It lets you hook all the builtins, getting attributes, writing to local variables, and importing. You could use this to prevent access to anything you want. As far as I can tell, Python is used in ages for game logic only, with some exceptions in the KI, so it should only be allowed to access Plasma API calls. No open, no modules, nothing but Plasma.

(If anyone with more experience with Plasma & Python knows more about this, it'd be cool to learn. I can't conceive of a reason an age would need even sys or os, but I could be thinking wrong.)

Keikoku wrote:
Given the overall amount of work in creating in age, I'm sceptical that someone would abandon their work over something so minor.


I doubt people would drop an age entirely, but it would certainly be disheartening. It could keep people from writing ages. I still think that this is a good direction to head in, but the migration would have to be handled delicately.

Keikoku wrote:
But I'm looking towards a future where you can walk into a library containing shelf upon shelf of linking books, pick one at random and link there. In turn, those ages may have their own libraries of books; IOW, a "web" of ages.


You're future of a "web of ages" is a future I hope for too. It's what I always wanted Uru to be...


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Feb 23, 2010 9:27 pm 
Offline

Joined: Fri Feb 19, 2010 5:04 pm
Posts: 115
Location: England
agrif wrote:
I looked around at various Python sandboxing techniques, and found RestrictedPython.

rexec and Bastion both made it into the standard library, but they've been removed in Python 3 because they've never managed to close all of the loopholes. And there's also SafeLite, which is currently in the early stages of the inevitable whac-a-mole game. At this rate, there'll soon be enough for a "top ten" list.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Feb 23, 2010 9:49 pm 
Offline
Obduction Backer

Joined: Wed May 31, 2006 4:09 am
Posts: 20
The difference here is that we don't really want any of the more advanced features of Python (again, with the notable exception of the KI and other preexisting Cyan stuff). We can simply lock out all imports that aren't Plasma, make sure Plasma doesn't give any Python classes to the script (excepting integers, strings, ...), and prune the builtin list to remove 'open', 'reload', 'compile', 'eval', 'execfile', 'file', 'input', and 'raw_input'.

We don't need anything but a turing-complete language with access to the Plasma API. By removing all of these, that's what we end up with.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Feb 23, 2010 10:13 pm 
Offline

Joined: Tue May 09, 2006 4:24 pm
Posts: 3120
Location: Aachen, Germany
Shorah everybody!

Security isn't that much of an issue if you can modify the implementation of the Python interpreter itself. Most security approaches like rexec and Safelite are trying to secure a standard and stock interpreter from within. Since Uru is shipped with a builtin and custom Python interpreter anyway it's not much hard work to secure the interpreter properly. All we have to do is to exclude any objects and functions that may be abused for breaking security. The Google App Engine is a very good example for a secured and custom Python interpreter.

I've detailed knowledge of the inner workingss of the CPython interpreter. I can assure you that it's a feasible and realizable task. Last week I already promised Mark to assist with my Python Fu.

I don't see a good reason to move to Lua. While Lua is a good embedded language for scripting Python is superior in its possibilities. Also it's going to take a LOT of effort to port all existing Python code to Lua. The decompyled PAK files have a total line count of approx. 150,000. The favorite community tool for age creating has powerful Python bindings. Why waste precious time to rewrite all code, force every age creator to learn yet another one that isn't as useful as Python and replace a tool by a less powerful one?

Tiran

PS: I'm back ;)

_________________
Image
[KI again #01792364]| Uru images | KI guide


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Feb 24, 2010 12:50 am 
Offline

Joined: Fri Feb 19, 2010 5:04 pm
Posts: 115
Location: England
Tiran wrote:
Security isn't that much of an issue if you can modify the implementation of the Python interpreter itself. Most security approaches like rexec and Safelite are trying to secure a standard and stock interpreter from within. Since Uru is shipped with a builtin and custom Python interpreter anyway it's not much hard work to secure the interpreter properly. All we have to do is to exclude any objects and functions that may be abused for breaking security. The Google App Engine is a very good example for a secured and custom Python interpreter.

My main concern is whether core modules require dangerous functionality. Obviously the interpreter itself needs to be able to read files, but what I don't know is whether any of that leaks into Python-land. If it does, trying to limit which parts of the code can access it seems to be a fool's errand.

If anything dangerous simply isn't available to (any) Python code, then there isn't likely to be a problem (so long as it stays that way; I can imagine security versus functionality becoming an ongoing battle). The problems start when something has to be available to some piece of code and you're trying to prevent references from leaking to anything else.

IOW, excluding dangerous functionality altogether is a viable strategy; trying to merely restrict it probably isn't. Either the genie is safely in the bottle or it's out.

Tiran wrote:
I've detailed knowledge of the inner workings of the CPython interpreter. I can assure you that it's a feasible and realizable task. Last week I already promised Mark to assist with my Python Fu.

Okay; that moves it into the realm of feasibility. Are you familiar with the specifics of Python as implemented by Uru? Not necessarily the internals, but what's available and what isn't?

If security can be obtained without changing languages, all the better. My main concern is to avoid seeing the responsibility for security pushed onto the players, leaving everyone stuck inside gated communities because clicking on the wrong link is too dangerous.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Feb 24, 2010 2:25 am 
Offline
Obduction Backer

Joined: Wed May 31, 2006 4:09 am
Posts: 20
Keikoku wrote:
If anything dangerous simply isn't available to (any) Python code, then there isn't likely to be a problem (so long as it stays that way; I can imagine security versus functionality becoming an ongoing battle). The problems start when something has to be available to some piece of code and you're trying to prevent references from leaking to anything else.

IOW, excluding dangerous functionality altogether is a viable strategy; trying to merely restrict it probably isn't. Either the genie is safely in the bottle or it's out.


This is a good point, and it troubled me when I thought about how we could continue to use Python but keep it locked down. As far as I'm aware, the KI code (written in Python) opens and writes files whenever an picture is taken. Python still has to have the ability to save files... so how can we keep file-opening limited to only KI code?

In Uru, every age (and here, the KI counts as an "age") has a unique ID. Interestingly, the more system-oriented ages (like the KI, and custom avatars, etc) all have negative IDs. A custom-built age has no business having a negative ID, so we can let scripts attached to negative-id ages do whatever they want, and otherwise lock things down. Then, just refuse to download negative-id ages just from linking.

I'm assuming here that we can switch on and off the lock-down on the interpreter at will... which may be tricky. That's why I was looking for a solution written in Python. RestricedPython compiles code into a restricted code object, so that makes it easy. A solution outside the interpreter would surely be more secure, but it might be harder to select what scripts get access.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Feb 24, 2010 3:25 am 
Offline

Joined: Sat Apr 14, 2007 9:51 pm
Posts: 265
The following post is written as if age viruses et al. are a big threat.

As I see it, with any software it is in the end the responsibility of the end user to decide if a program/age/plugin/ascii text file/jpeg/etc is safe enough for them to use. It's easy to get malware on Windows if you're not careful, firewalls can't really protect you; all they can do is ask you a question you can't usually answer "Is this a bad program <insert odd name that sounds like a system thing>?".

The real problem I see is people who _do_ care about keeping their computer clean (the people who look up suspicious registry entries just to be sure) not understanding how to be safe on Uru. What I think is called for is some sort of sinister code detection that you can have scan before you link to the age. There could be a small in game application that scans the code for a list of commands, for instance, "open" and tells you about it. It can provide recommendations: "ages don't usually use the "open" function, this is potentially hazardous". If you don't feel like taking the risk you can not link to the age and consult an expert (if the age's code hasn't already been looked over).

I think care (checksums) should be taken to make sure you're not getting a modified version of a tested age without knowing it. If I had malicious intent I would most likely put my code in a preexisting age.

_________________
Guild of Writers Councilor
PyPRP2 Developer
Plasma Hacker


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Feb 24, 2010 6:09 am 
Offline
Obduction Backer

Joined: Thu Jun 08, 2006 7:01 pm
Posts: 1890
I sense a certain cyclicality in this discussion. :)

_________________
Andrew Plotkin -- Seltani founding member


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Feb 24, 2010 1:00 pm 
Offline

Joined: Fri Feb 19, 2010 5:04 pm
Posts: 115
Location: England
agrif wrote:
Keikoku wrote:
If anything dangerous simply isn't available to (any) Python code, then there isn't likely to be a problem (so long as it stays that way; I can imagine security versus functionality becoming an ongoing battle). The problems start when something has to be available to some piece of code and you're trying to prevent references from leaking to anything else.

IOW, excluding dangerous functionality altogether is a viable strategy; trying to merely restrict it probably isn't. Either the genie is safely in the bottle or it's out.


This is a good point, and it troubled me when I thought about how we could continue to use Python but keep it locked down. As far as I'm aware, the KI code (written in Python) opens and writes files whenever an picture is taken. Python still has to have the ability to save files... so how can we keep file-opening limited to only KI code?


The way you'd normally do it would be to implement a C/C++ function to take and save a snapshot, and expose that function to Python. The KI code can call that function, which results in a file being saved. However, the code doesn't get to choose the nature of the file (i.e. it can't create an EXE) or the location (it's restricted to the snapshots directory) or even the filename.

agrif wrote:
In Uru, every age (and here, the KI counts as an "age") has a unique ID. Interestingly, the more system-oriented ages (like the KI, and custom avatars, etc) all have negative IDs. A custom-built age has no business having a negative ID, so we can let scripts attached to negative-id ages do whatever they want, and otherwise lock things down. Then, just refuse to download negative-id ages just from linking.


The problem there is that I suspect there are a lot of people who would like to enhance the KI in some way. OTOH, that's the sort of situation where it's feasible to manage a trust relationship, i.e. KI upgrades would have to be specifically downloaded.

agrif wrote:
I'm assuming here that we can switch on and off the lock-down on the interpreter at will... which may be tricky. That's why I was looking for a solution written in Python. RestricedPython compiles code into a restricted code object, so that makes it easy. A solution outside the interpreter would surely be more secure, but it might be harder to select what scripts get access.


I don't know anything about running multiple Python interpreters in a single process. I do know that this is trivially easy to do with JavaScript (e.g. web browsers typically run a separate interpreter for each window or tab).

Being able to set the globals for exec/eval provides some isolation, but not as much as people often assume. If any object is shared between contexts, there's a risk of an untrusted context monkey-patching an object with code which will subsequently be executed within a trusted context.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Feb 24, 2010 1:25 pm 
Offline

Joined: Fri Feb 19, 2010 5:04 pm
Posts: 115
Location: England
Lontahv wrote:
The following post is written as if age viruses et al. are a big threat.

They will be if a fully open Myst universe takes off. The risk is mitigated at present by the need for a significant level of manual intervention.

Lontahv wrote:
The real problem I see is people who _do_ care about keeping their computer clean (the people who look up suspicious registry entries just to be sure) not understanding how to be safe on Uru. What I think is called for is some sort of sinister code detection that you can have scan before you link to the age. There could be a small in game application that scans the code for a list of commands, for instance, "open" and tells you about it.

This isn't a feasible solution. The nature of dynamic languages is such that it's (provably) impossible to detect in advance what the script will try to do. Instead, the interpreter needs to be hardened so that it doesn't matter what the script tries to do, any dangerous functionality simply isn't available from within the interpreter.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Feb 24, 2010 1:51 pm 
Offline

Joined: Tue May 09, 2006 4:24 pm
Posts: 3120
Location: Aachen, Germany
Keikoku wrote:
This isn't a feasible solution. The nature of dynamic languages is such that it's (provably) impossible to detect in advance what the script will try to do. Instead, the interpreter needs to be hardened so that it doesn't matter what the script tries to do, any dangerous functionality simply isn't available from within the interpreter.


You are correct! Security measures should be implemented as simple as possible. Anything that is complex, hard to implement or hard to explain is more likely to break. This is especially true if more than one developer is going to touch the code. There are multiple ways to harden a Python interpreter with rexec, safelite and subinterpreters. But I strongly recommend to walk a different path. Since we have full control over the included implementation of Python it's easier and more secure to modify the interpreter.

Before I reply to the other replies to my posting I like to lay common grounds. What do we have to restrict.

Python code = any code written in Python and included with MOUL as part of the Python standard library or age code.

* Python code must not read or write any files from the file system
* Python code must not be able to open sockets in order to make network connections to different hosts
* Python code must not be able to shut down or crash the interpreter
* Python code must not be able to load extensions (DLLs) which might allow users to add new features
* Python code must not be allowed to load additional modules from the file system
* Python code must use proper plasma API calls to interact with the server and fault
* Any unused or possible harmful model isn't part of the MOUL Python package.

_________________
Image
[KI again #01792364]| Uru images | KI guide


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 100 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
cron