Re: [pygame] Scripting language

2006-12-22 Thread Laura Creighton
In a message of Fri, 22 Dec 2006 14:39:52 +0100, Troels Therkelsen writes:
>I know it's pretty late in the discussion, but have you considered PyPy, 
>Brandon?  While I haven't looked at it extensively, the python-in-python 
>would indicate that you could make arbitrary security checks pretty much 
>anywhere?
>
>-- 
>Med venlig hilsen / Best regards,
>
>Troels Therkelsen
>Programmer
>Nitram Lexa ApS
>Maglebjergvej 5A
>DK-2800 Kongens Lyngby
>Denmark

Ah, eventually, yes.  But we are still at the 'bleeding edge research'
stage of the project and not really suitable for application
development yet.  This will change, but unless you plan a really
long development cycle, I think you will need to find a different
solution for now.

Laura


Re: [pygame] Scripting language

2006-12-22 Thread Troels Therkelsen
I know it's pretty late in the discussion, but have you considered PyPy, 
Brandon?  While I haven't looked at it extensively, the python-in-python 
would indicate that you could make arbitrary security checks pretty much 
anywhere?


--
Med venlig hilsen / Best regards,

Troels Therkelsen
Programmer
Nitram Lexa ApS
Maglebjergvej 5A
DK-2800 Kongens Lyngby
Denmark

Phone: +45 70 25 24 23
Fax: +45 70 25 29 23
Mobile: +45 25 39 14 69 


E-mail: [EMAIL PROTECTED]
Web: www.nitramlexa.com

Internet - e-learning - video streaming





Re: [pygame] Scripting language

2006-12-19 Thread Greg Ewing

Ethan Glasser-Camp wrote:


However, when I tried to exploit this in my level file format, I got:

IOError: file() constructor not accessible in restricted mode


There are still remnants of the old restricted mode
around, and they may prevent some exploits of this
kind. But considering that the above trick can be
used to get hold of *any* builtin or new-style
class in the system (they're all ultimately subclasses
of object) you could never be sure that all possible
exploits had been blocked.


Where can I find information on these efforts?


There were discussions about it on the python-dev
list recently.

--
Greg


Re: [pygame] Scripting language

2006-12-19 Thread Greg Ewing

Richard Tew wrote:

On 12/19/06, Greg Ewing <[EMAIL PROTECTED]> wrote:

> But what about things like
>
> x = 1000 ** 1



if you were
satisfied with whatever trivial level of Python the recipe could
allow, then I imagine this would be something you could use
that to guard against.


You couldn't prevent that with bytecode analysis, unless
you disallowed all use of arithmetic.

--
Greg


Re: [pygame] Scripting language

2006-12-19 Thread Nicola Larosa
Jakub Piotr Cłapa wrote:
>>> That's the reason why restricted execution was withdrawn from the
>>> stdlib. Nobody seems to care about security enught to handle this
>>> (rather difficult) problem.

> Greg Ewing wrote:
>> That's not entirely true -- there are efforts underway to
>> come up with a new model for sandboxed execution. It'll probably
>> be a while before anything usable comes out of that, though.

Ethan Glasser-Camp wrote:
> Where can I find information on these efforts?

Still working on security
http://sayspy.blogspot.com/2006/07/still-working-on-security.html

Securing Python
http://svn.python.org/view/*checkout*/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717


-- 
Nicola Larosa - http://www.tekNico.net/

I'm creating things now that I want to be able to read, hear, watch,
search, and filter 50 years from now. Despite all their emphasis on con-
tent creators, Apple has made it clear that they do not share this goal.
Openness is not a cargo cult. Some get it, some don't. Apple doesn't.
 -- Mark Pilgrim, June 2006



Re: [pygame] Scripting language

2006-12-19 Thread Bob Ippolito

On 12/19/06, Jakub Piotr Cłapa <[EMAIL PROTECTED]> wrote:

Bob Ippolito wrote:
> On 12/19/06, Jakub Piotr Cłapa <[EMAIL PROTECTED]> wrote:
>> Farai Aschwanden wrote:
>> > Hmm true for file opening. Adding paths needs the OS module, but you're
>> > right.
>> >
>> > I like the way Brian just sent before. I dont know any language that
>> > restricts its usage (would be neat feature for certain projects).
>>
>> Check PLT-Scheme for example. Neko also seems securable. An of course
>> LPC (search for DGD). The endless loop thing can be solved by
>> multithreading and killing any threads that run to long.
>
> That's not really a solution, pthreads can't be reliably killed. You'd
> still need a different abstraction that guarantees that you can kill
> threads in a reasonable amount of time.

There are languages with user-level threads (which are perfect for most
game logic kind of programming) like Erlang/PLT-Scheme AFAIK.
Still, could you please elaborate on the problems with killing pthreads
(let's forget about garbage collection and such)? Do you mean problems
with interrupting system calls?


By "different abstraction"  I was referring to the kind of user-level
threads that you were referring to.
Erlang doesn't call them threads; they're processes. I don't know what
PLT-Scheme calls them, but if it's just "threads" then that's probably
a mistake -- most people associate threads with pthreads. The term
process is pretty overloaded too, but Erlang's processes are pretty
close to an OS process... they're just much cheaper to use (in time
and space).

Pthreads can't be reliably killed cross-platform, period. pthread_kill
is simply broken, it's not a very well designed API.


> You may want to take a look at embedding SpiderMonkey. It's designed
> to meet all of the given constraints (for the browser environment),
> and it's a language that's well known and easily learned (JavaScript).

That's probably a good idea however looking on Mozilla I'm unsure
whether it's protection from endless loops is flexible enough. (on the
other side it appeared only recently in the UI so maybe it's better
underneath) ;-)


It certainly works well enough to run it on a client.

-bob


Re: [pygame] Scripting language

2006-12-19 Thread Marius Gedminas
On Tue, Dec 19, 2006 at 12:27:02AM +0100, Jakub Piotr Cłapa wrote:
> The problem is that disk access is a built-in in Python. And if you want 
> to expose anything than you leave a way to go through your function to 
> your module and than to anything you want. That's the reason why 
> restricted execution was withdrawn from the stdlib. Nobody seems to care 
> about security enught to handle this (rather difficult) problem.

Brett Cannon is working on this problem.

  http://sayspy.blogspot.com/2006/05/researching-programming-language.html
  http://sayspy.blogspot.com/2006/07/security-design-doc-using-object.html
  and several subsequent posts

Marius Gedminas
-- 
The last good thing written in C was Franz Schubert's Symphony #9.
-- Erwin Dietrich


signature.asc
Description: Digital signature


Re: [pygame] Scripting language

2006-12-19 Thread Jakub Piotr Cłapa

Brandon N wrote:
  I have found a Python in Ruby, but is there a Ruby in Python or Lua 
for that matter?


You could check (or implement) some Lisp. It's not what most people see 
in their mind when they think end-user programming but it's quite simple 
to implement and you can always do a translating front end to add some 
syntactic sugar. There were some projects implementing a dialect of Lisp 
in Python (and vice-versa) you could search for.


--
regards,
Jakub Piotr Cłapa


Re: [pygame] Scripting language

2006-12-19 Thread Jakub Piotr Cłapa

Bob Ippolito wrote:

On 12/19/06, Jakub Piotr Cłapa <[EMAIL PROTECTED]> wrote:

Farai Aschwanden wrote:
> Hmm true for file opening. Adding paths needs the OS module, but you're
> right.
>
> I like the way Brian just sent before. I dont know any language that
> restricts its usage (would be neat feature for certain projects).

Check PLT-Scheme for example. Neko also seems securable. An of course
LPC (search for DGD). The endless loop thing can be solved by
multithreading and killing any threads that run to long.


That's not really a solution, pthreads can't be reliably killed. You'd
still need a different abstraction that guarantees that you can kill
threads in a reasonable amount of time.


There are languages with user-level threads (which are perfect for most 
game logic kind of programming) like Erlang/PLT-Scheme AFAIK.
Still, could you please elaborate on the problems with killing pthreads 
(let's forget about garbage collection and such)? Do you mean problems 
with interrupting system calls?



You may want to take a look at embedding SpiderMonkey. It's designed
to meet all of the given constraints (for the browser environment),
and it's a language that's well known and easily learned (JavaScript).


That's probably a good idea however looking on Mozilla I'm unsure 
whether it's protection from endless loops is flexible enough. (on the 
other side it appeared only recently in the UI so maybe it's better 
underneath) ;-)


--
regards,
Jakub Piotr Cłapa


Re: [pygame] Scripting language

2006-12-19 Thread Bob Ippolito

On 12/19/06, Jakub Piotr Cłapa <[EMAIL PROTECTED]> wrote:

Farai Aschwanden wrote:
> Hmm true for file opening. Adding paths needs the OS module, but you're
> right.
>
> I like the way Brian just sent before. I dont know any language that
> restricts its usage (would be neat feature for certain projects).

Check PLT-Scheme for example. Neko also seems securable. An of course
LPC (search for DGD). The endless loop thing can be solved by
multithreading and killing any threads that run to long.


That's not really a solution, pthreads can't be reliably killed. You'd
still need a different abstraction that guarantees that you can kill
threads in a reasonable amount of time.

You may want to take a look at embedding SpiderMonkey. It's designed
to meet all of the given constraints (for the browser environment),
and it's a language that's well known and easily learned (JavaScript).

-bob


Re: [pygame] Scripting language

2006-12-19 Thread Jakub Piotr Cłapa

Farai Aschwanden wrote:
Hmm true for file opening. Adding paths needs the OS module, but you're 
right.


I like the way Brian just sent before. I dont know any language that 
restricts its usage (would be neat feature for certain projects).


Check PLT-Scheme for example. Neko also seems securable. An of course 
LPC (search for DGD). The endless loop thing can be solved by 
multithreading and killing any threads that run to long.


--
regards,
Jakub Piotr Cłapa


Re: [pygame] Scripting language

2006-12-18 Thread Ethan Glasser-Camp
Greg Ewing wrote:
> Type "help", "copyright", "credits" or "license" for more information.
 (3).__class__.__bases__[0].__subclasses__()[-3]
> 

Wow, this almost made me fall out of my chair! I use a whitelist
technique to disallow calls to all builtins, but I had no idea you
could do this. Thanks for that!

However, when I tried to exploit this in my level file format, I got:

IOError: file() constructor not accessible in restricted mode

So I guess it's more complicated than that. It looks like calling
eval() or execfile() puts code in "restricted mode" regardless, and
disallows file construction period. To quote Steven Bethard on
comp.lang.python:

"I believe the official stance is something like: 'Well restricted
mode probably works in a lot of cases, but we're not confident enough
in it (having found bugs in it over and over) that we'd suggest it for
production use.'"

>> That's the reason why restricted execution was withdrawn from the
>> stdlib. Nobody seems to care about security enught to handle this
>> (rather difficult) problem.
> 
> That's not entirely true -- there are efforts underway to
> come up with a new model for sandboxed execution. It'll probably
> be a while before anything usable comes out of that, though.

Where can I find information on these efforts?

Ethan



signature.asc
Description: OpenPGP digital signature


Re: [pygame] Scripting language

2006-12-18 Thread David Gowers

BTW, it's perfectly possible to eliminate open() and file() from usability.
The only problem is it requires a separate instance of __bulitins__
(therefore probably a separate interpreter)

Try 1:


def fakeopen (filename, mode = 'r', buffering = 0):

... raise NotImplementedError
...


__builtins__.open = fakeopen
__builtins__.file = fakeopen
open ('/dev/urandom', 'rb')

Traceback (most recent call last):
 File "", line 1, in 
 File "", line 2, in fakeopen
NotImplementedError



Try 2 (no, you don't need another interpreter instance!)


def fakeopen (filename, mode = None, buffering = None):

... raise NotImplementedError
...

newbuiltins = dict (vars (__builtins__))
env = {}
newbuiltins['open'] = fakeopen
newbuiltins['file'] = fakeopen
env['__builtins__'] = newbuiltins
# Try to do something VERBOTEN.
script = "f = open('/dev/random','r'); randombyte = f.read (1)"
exec script in env

Traceback (most recent call last):
 File "", line 1, in 
 File "", line 1, in 
 File "", line 2, in fakeopen
NotImplementedError

# now see what nested exec does..

...


script = """exec "f = open('/dev/random','r'); randombyte = f.read(1)";"""



exec script in env

Traceback (most recent call last):
 File "", line 1, in 
 File "", line 1, in 
 File "", line 1, in 
 File "", line 2, in fakeopen
NotImplementedError

# still works!

...

Unless there is some way to access open() via modules' __builtins__
attribute, or functions' func_globals attribute..

And there is. But it's caught!

script = """exec "import os; f = os.__builtins__['open']('/dev/random','r');
randombyte = f.read(1);f.close()";"""

exec script in env

Traceback (most recent call last):
 File "", line 1, in 
 File "", line 1, in 
 File "", line 1, in 
IOError: file() constructor not accessible in restricted mode




I am running Python 2.6 here, and evidently setting __builtins__ in a
globals dictionary activates restricted mode for anything running in it.

Testing nestedness

# now for extreme convolution

...

script = """exec "f = open('/dev/random','r'); randombyte =

f.read(1);f.close()"
in os.__builtins__"""

exec script in env

Traceback (most recent call last):
 File "", line 1, in 
 File "", line 1, in 
 File "", line 1, in 
IOError: file() constructor not accessible in restricted mode

:D

Testing silly degree of nestedness:

#and ultimate convolution

...

script = """exec "exec \\\"f = open('/dev/random','r'); randombyte =

f.read(1);f.close()\\\"" in os.__builtins__"""

exec script in env

Traceback (most recent call last):
 File "", line 1, in 
 File "", line 1, in 
 File "", line 1, in 
 File "", line 1, in 
IOError: file() constructor not accessible in restricted mode

So that's pretty locked-down (I haven't tested the os module -- get a
checkout of SVN python if you want to do that.)


Greg, in Python 2.6:

Python 2.6a0 (trunk:52884, Dec  1 2006, 14:21:57)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

(3).__class__.__bases__[0].__subclasses__()[-3]




(3).__class__.__bases__[0].__subclasses__()[-29]




# It's a nice hack, but it doesn't help you evade restrictions:
exec "(3).__class__.__bases__[0].__subclasses__()[-29]('/dev/urandom')"

in env
Traceback (most recent call last):
 File "", line 1, in 
 File "", line 1, in 
IOError: file() constructor not accessible in restricted mode


The two other major issues are looping-forever (which can't be fixed really,
except by restricting execution time) and memory usage (I accidentally
created a infinite loop today that expanded Python's memory usage to 500mb).
Greg's idea of running as a seperate process is good for addressing those.

Re: imports -- probably the only fully safe way is to prohibit them
completely, and pre-import chosen safe modules for your scripts' use.


Re: [pygame] Scripting language

2006-12-18 Thread Tim Ansell
On Mon, 2006-12-18 at 16:53 -0500, Brandon N wrote:
> Hello all,
>This is not strictly a pygame question though it does relate to my  
> use of pygame in general. What have people used for scripting  
> languages in Python? I suppose I could use Python itself but I do not  
> want to expose anything through the use of eval or otherwise  
> (currently I am doing just about this). While I do not want to write  
> a language from scratch, I do have a simple Lisp implementation that  
> I could expose.

I would recommend using Scheme :P 

For my project (Thousand Parsec - http://www.thousandparsec.net ) we had
a similar problem. To make the matters worse we also need it to be
compatible across C++, Java, PHP, etc. (I even found an implementation
in Javascript!)

We found that Scheme is the only full language which been reimplemented
in almost every other language under the sun. 

Scheme is very closely related to lisp only is much smaller. There are a
few pure python implementations such as pyScheme. You can also wrap C
libraries such as mzscheme and guile. It is also pretty trivial to write
your own scheme parser and often turns up as an assignment in Computer
Science courses.

The biggest downside of Scheme is that it's bracket soup. Programs like
DrScheme are pretty good in helping you write it however. If you are
using Lisp anyway then this isn't a problem for you.

Hope this help.

Tim Ansell

> If this is way too off-topic I'll try to find another place to ask.
> 
> Cheers,
>Brandon



Re: [pygame] Scripting language

2006-12-18 Thread R. Alan Monroe
> I've been reading up on perspective broker since you emailed it and I  
> think a solution of that sort is the most likely that I will end up  
> with.

Also check out a competing but lesser known technology: "Ice" from
http://www.zeroc.com/

Alan



Re: [pygame] Scripting language

2006-12-18 Thread Richard Tew

On 12/19/06, Greg Ewing <[EMAIL PROTECTED]> wrote:

Richard Tew wrote:
>> while True:
>>   pass
>>
>> def fib(n):
>>   return fib(n-1) + fib(n-2)
>> fib(100)
>
> If you were using Stackless Python, this sort of thing could
> easily be detected, interrupted and discarded.

But what about things like

x = 1000 ** 1


No :)  Stackless' "run for so many Python instructions" mode
would not be able to do anything about that.  But if you were
satisfied with whatever trivial level of Python the recipe could
allow, then I imagine this would be something you could use
that to guard against.


> I wonder if this recipe were taken to the safe extreme, how
> much of a subset of Python could be safely allowed:
>
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/286134

Probably not feasible to relax it enough to allow
non-trivial code without opening up unwanted abilities.


Perhaps.  It would be an interesting project for someone to take
up though in order to see how far it can be taken safely.

Richard.


Re: [pygame] Scripting language

2006-12-18 Thread Greg Ewing

Richard Tew wrote:

while True:
  pass

def fib(n):
  return fib(n-1) + fib(n-2)
fib(100)


If you were using Stackless Python, this sort of thing could
easily be detected, interrupted and discarded.


But what about things like

   x = 1000 ** 1


I wonder if this recipe were taken to the safe extreme, how
much of a subset of Python could be safely allowed:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/286134


Probably not feasible to relax it enough to allow
non-trivial code without opening up unwanted abilities.

--
Greg


Re: [pygame] Scripting language

2006-12-18 Thread Greg Ewing

Jakub Piotr Cłapa wrote:
And if you want 
to expose anything than you leave a way to go through your function to 
your module and than to anything you want.


Just to bring this into sharp focus, consider

Python 2.3 (#1, Aug  5 2003, 15:52:30)
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> (3).__class__.__bases__[0].__subclasses__()[-3]


So you don't even have to import anything or refer to any
names in the builtin namespace to wreak havoc.

That's the reason why 
restricted execution was withdrawn from the stdlib. Nobody seems to care 
about security enught to handle this (rather difficult) problem.


That's not entirely true -- there are efforts underway to
come up with a new model for sandboxed execution. It'll probably
be a while before anything usable comes out of that, though.

As things are, the only way to be completely sure that the
user's code can't mess anything up is to run it in a separate
process. That has other advantages, too, such as being able
to limit memory and CPU usage, which are also difficult or
impossible to do within a single Python process.

--
Greg


Re: [pygame] Scripting language

2006-12-18 Thread Richard Tew

On 12/19/06, robomancer <[EMAIL PROTECTED]> wrote:

On the other hand, allowing people to run arbitrary code on your
machine is a Bad Idea even if you *can* ensure that the filesystem
isn't touched.  What if they send any of the following?

while True:
  pass

def fib(n):
  return fib(n-1) + fib(n-2)
fib(100)


If you were using Stackless Python, this sort of thing could
easily be detected, interrupted and discarded.  You could
then flag the user who wrote the overly intensive logic
and refuse to run any more (or whatever).


def steal_data():
  send_to_client("127.0.0.1", pickle.dump(confidential.data.structure)


I wonder if this recipe were taken to the safe extreme, how
much of a subset of Python could be safely allowed:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/286134

Richard.


Re: [pygame] Scripting language

2006-12-18 Thread JoN
This is something I'm very interested in.
I'm wondering if Van Rossum is thinking about this these days, but he's been
close-lipped about it on the searches I've done so far.

You can restrict access to imported classes and methods by fiddling with
Properties, kinda easily enough, but then how to apply an access model to it?
Particularly in a PyThreads environment, which is what I'm looking at.

Guess this is well off-topic for pygame but thought I'd throw some petrol on the
fire.

Jon


Quoting Brandon N <[EMAIL PROTECTED]>:

> I've been reading up on perspective broker since you emailed it and I  
> think a solution of that sort is the most likely that I will end up  
> with.
> 
> As for the examples you have posted, I had a rudimentary Python-like  
> scripting language I've been building that is translated to Python  
> after validation (against things like forever loops, unregistered  
> function calls and the like), but I agree that no amount of work will  
> really close the gaping holes that exist for abuse my malicious and  
> unknowing users.
> 
> Cheers,
>Brandon
> 
> On Dec 18, 2006, at 7:14 PM, robomancer wrote:
> 
> >> I like the way Brian just sent before. I dont know any language that
> >> restricts its usage (would be neat feature for certain projects).
> >
> > Perl has "taint mode".  When enabled, Perl won't let you do any
> > "dangerous" operations (file accesses, system calls, etc) on data that
> > originally came from the user and hasn't been processed to remove its
> > "taintedness".
> >
> > On the other hand, allowing people to run arbitrary code on your
> > machine is a Bad Idea even if you *can* ensure that the filesystem
> > isn't touched.  What if they send any of the following?
> >
> > while True:
> >  pass
> >
> > def fib(n):
> >  return fib(n-1) + fib(n-2)
> > fib(100)
> >
> > def steal_data():
> >  send_to_client("127.0.0.1", pickle.dump(confidential.data.structure)
> >
> > There are just so many ways to exploit arbitrary code execution, from
> > malicious data corruption to denial-of-service to buffer-overflow
> > exploits (yes, this is possible even from within Python, if you use
> > any buggy C extension modules)... it's *really* not a good idea.  A
> > lot of very smart people have worked hard to solve this sort of
> > problem, and not made much progress.
> >
> > I either recommend having an explicit server/client API and forcing
> > people to use that API (whether it's invoked via Perspective Broker as
> > I suggested earlier, or something more standard like XML-RPC, CORBA,
> > or SOAP), or not allowing a "scripting language" at all, instead
> > opting for something like customizable configuration files that aren't
> > Turing-complete.
> 
> 





Come and visit Web Prophets Website at http://www.webprophets.net.au



Re: [pygame] Scripting language

2006-12-18 Thread Brandon N
I've been reading up on perspective broker since you emailed it and I  
think a solution of that sort is the most likely that I will end up  
with.


As for the examples you have posted, I had a rudimentary Python-like  
scripting language I've been building that is translated to Python  
after validation (against things like forever loops, unregistered  
function calls and the like), but I agree that no amount of work will  
really close the gaping holes that exist for abuse my malicious and  
unknowing users.


Cheers,
  Brandon

On Dec 18, 2006, at 7:14 PM, robomancer wrote:


I like the way Brian just sent before. I dont know any language that
restricts its usage (would be neat feature for certain projects).


Perl has "taint mode".  When enabled, Perl won't let you do any
"dangerous" operations (file accesses, system calls, etc) on data that
originally came from the user and hasn't been processed to remove its
"taintedness".

On the other hand, allowing people to run arbitrary code on your
machine is a Bad Idea even if you *can* ensure that the filesystem
isn't touched.  What if they send any of the following?

while True:
 pass

def fib(n):
 return fib(n-1) + fib(n-2)
fib(100)

def steal_data():
 send_to_client("127.0.0.1", pickle.dump(confidential.data.structure)

There are just so many ways to exploit arbitrary code execution, from
malicious data corruption to denial-of-service to buffer-overflow
exploits (yes, this is possible even from within Python, if you use
any buggy C extension modules)... it's *really* not a good idea.  A
lot of very smart people have worked hard to solve this sort of
problem, and not made much progress.

I either recommend having an explicit server/client API and forcing
people to use that API (whether it's invoked via Perspective Broker as
I suggested earlier, or something more standard like XML-RPC, CORBA,
or SOAP), or not allowing a "scripting language" at all, instead
opting for something like customizable configuration files that aren't
Turing-complete.




Re: [pygame] Scripting language

2006-12-18 Thread JoN
Sorry, I disagree (let's flaame!!  ;) )

When you initially cook up a 'little scripting language', and there it sits,
dripping wet and shining new, it usually does what you want.  Pretty much.  
Almost.

Then you go to add something.   Then something else.   Then you find a bug

Pretty soon you find yourself wondering "Gee, I've basically re-written
something that already exists and works better than what I've done anyway".

Been there!  Done that!

My 2c!  :)


Jon



Quoting Brian Fisher <[EMAIL PROTECTED]>:

> On 12/18/06, JoN <[EMAIL PROTECTED]> wrote:
> > Generally when you've got an excellent scripting language already, and
> lets'
> > face it Python is the Best (:)), re-inventing the wheel is not something
> you
> > want to do!
> >
> I totally agree that re-inventing the wheel is not something you want
> to do - but trying to use the very best jet engine in the world as a
> wheel on your car... won't have your car performing well as a car (or
> as a jet)
> 
> Basically, I think some "scripting" options that don't have users
> typing out code make a lot of sense for certain classes of stuff
> 





Come and visit Web Prophets Website at http://www.webprophets.net.au



Re: [pygame] Scripting language

2006-12-18 Thread robomancer

I like the way Brian just sent before. I dont know any language that
restricts its usage (would be neat feature for certain projects).


Perl has "taint mode".  When enabled, Perl won't let you do any
"dangerous" operations (file accesses, system calls, etc) on data that
originally came from the user and hasn't been processed to remove its
"taintedness".

On the other hand, allowing people to run arbitrary code on your
machine is a Bad Idea even if you *can* ensure that the filesystem
isn't touched.  What if they send any of the following?

while True:
 pass

def fib(n):
 return fib(n-1) + fib(n-2)
fib(100)

def steal_data():
 send_to_client("127.0.0.1", pickle.dump(confidential.data.structure)

There are just so many ways to exploit arbitrary code execution, from
malicious data corruption to denial-of-service to buffer-overflow
exploits (yes, this is possible even from within Python, if you use
any buggy C extension modules)... it's *really* not a good idea.  A
lot of very smart people have worked hard to solve this sort of
problem, and not made much progress.

I either recommend having an explicit server/client API and forcing
people to use that API (whether it's invoked via Perspective Broker as
I suggested earlier, or something more standard like XML-RPC, CORBA,
or SOAP), or not allowing a "scripting language" at all, instead
opting for something like customizable configuration files that aren't
Turing-complete.


Re: [pygame] Scripting language

2006-12-18 Thread Brandon N
I did find Lua in Python (http://labix.org/lunatic-python) though it  
seems to expose the Python environment within Lua which is a deal- 
breaker.


Re: [pygame] Scripting language

2006-12-18 Thread Brandon N

Yeah,
  I have been afraid of this being the case given that all my  
research indicated it. Thanks for the link, I agree that they are  
unsatisfactory, but at least it is a step in determining what exactly  
is available.


  Brian, I had actually given thought to something akin to the  
system you detailed after a discussion with a peer. I had also  
considered building a visual/drag-and-drop/list system that would  
output an easily verified python-like language. Upon receipt at the  
server, this would be validated (for variable use, methods) and  
converted to Python.


  Thanks everyone for the lively discussion. I am mostly surprised  
at the lack of a mainstream solution (or several) though I wonder if  
it is as a result of the common perception of C++ being "the" game  
development language and everything else being a secondary scripting  
language.


  I have found a Python in Ruby, but is there a Ruby in Python or  
Lua for that matter?


Cheers,
  Brandon

On Dec 18, 2006, at 6:27 PM, Bob the Hamster wrote:


I have read a lot about this, and the general consensus seems to be
that if you are worried about security, there is no known safe easy  
way
to embed python-in-python. That conclusion surprises and  
disappoints me,

but I can find no reliable information that contraticts it :(

Some unsatisfactory workarounds can be found at:
http://wiki.python.org/moin/ 
How_can_I_run_an_untrusted_Python_script_safely_(i.e._Sandbox)


---
Bob the Hamster




Re: [pygame] Scripting language

2006-12-18 Thread Brian Fisher

On 12/18/06, JoN <[EMAIL PROTECTED]> wrote:

Generally when you've got an excellent scripting language already, and lets'
face it Python is the Best (:)), re-inventing the wheel is not something you
want to do!


I totally agree that re-inventing the wheel is not something you want
to do - but trying to use the very best jet engine in the world as a
wheel on your car... won't have your car performing well as a car (or
as a jet)

Basically, I think some "scripting" options that don't have users
typing out code make a lot of sense for certain classes of stuff


Re: [pygame] Scripting language

2006-12-18 Thread Farai Aschwanden
Hmm true for file opening. Adding paths needs the OS module, but  
you're right.


I like the way Brian just sent before. I dont know any language that  
restricts its usage (would be neat feature for certain projects).



Am 19.12.2006 um 00:27 schrieb Jakub Piotr Cłapa:


Farai Aschwanden wrote:
Ok, as far as I understand now you want to let players changing  
their Avatars over a script language via Internet. Hmmm, nice  
feature letting players create their own scripts. Well, Im not a  
security guy but letting others use any (script) language that is  
technically able to access the directory structure of the system  
is risky. Whether its Python or any other not self written  
language you want to offer to you users I only see the following  
options:

- The user scripts are running on a exposed machine
- The user rights are strongly restricted
- The script language you offer to players is limited in its  
functionality (checking commands of players must be done then)
Maybe it already helps if you dont allow certain import  
functionalities (specially no direct disk access).


The problem is that disk access is a built-in in Python. And if you  
want to expose anything than you leave a way to go through your  
function to your module and than to anything you want. That's the  
reason why restricted execution was withdrawn from the stdlib.  
Nobody seems to care about security enught to handle this (rather  
difficult) problem.


--
regards,
Jakub Piotr Cłapa




Re: [pygame] Scripting language

2006-12-18 Thread Brian Fisher

On 12/18/06, Brandon N <[EMAIL PROTECTED]> wrote:

   Anyway, I am using Python as the development language for both the
client and server in a project I am working on. Now, I want to be
able to expose certain functionality for scripting other than the
internal development kind I have been doing with Python. That is,
users can write scripts that affect the behavior of their avatars in
the world.


Hmmm... if you want to have users able to write these scripts and you
want to have what they are capable of to be "sandboxed", I'd recommend
a system where scripting is done by creating instances of classes that
represent logic and actions in the scripting system, and then making
an editor that allows you to build trees of these objects by picking
which object you want connected to another (using a drop down) and
then you edit their properties to change what the actions & logic do.
So like, when your game objects execute script (on events or whatever)
that would look something like this:
  self.script.execute(self, context)
and maybe the userused the editor to make the script property point to
an instance of the IfThenScript class instance, which you wrote to
have an execute method something like this:
  def execute(self, owner, context):
  if self.condition.evaluate(owner, content):
 self.then_clause.execute(owner, context)
  else:
 self.else_clause.execute(owner, context)
and the IfThenScript instance's condition and then_clause and
else_clause would all be instances of some other scripting class types
you wrote that the user hooked up using the editor

I like it because then there is no parsing or syntax issues to deal
with (i.e it's hard for the user to make something invalid vs. them
having to type out code), and it's very easy for users to learn what
they can do because they have to pick which class they can use in what
situation from a list. Finally, it's easier to show and manipulate
visually if you do your editor well.

Python is good for this too because of all it's reflection
capabilities (you can enumerate derived classes, get class types,
enumerate properties, etc.). In addition python already has
serialization (so you can pretty much just pickle and unpickle your
trees of scripting objects, although you may want to do some extra
work there for the sake of security)

The biggest cost there would be writing an editor for users to build
and modify your scripting objects.


Re: [pygame] Scripting language

2006-12-18 Thread Bob the Hamster
> Quoting Brandon N <[EMAIL PROTECTED]>:
> 
> > Hello all,
> >This is not strictly a pygame question though it does relate to my  
> > use of pygame in general. What have people used for scripting  
> > languages in Python? I suppose I could use Python itself but I do not  
> > want to expose anything through the use of eval or otherwise  
> > (currently I am doing just about this). While I do not want to write  
> > a language from scratch, I do have a simple Lisp implementation that  
> > I could expose.

I have read a lot about this, and the general consensus seems to be 
that if you are worried about security, there is no known safe easy way 
to embed python-in-python. That conclusion surprises and disappoints me, 
but I can find no reliable information that contraticts it :(

Some unsatisfactory workarounds can be found at:
http://wiki.python.org/moin/How_can_I_run_an_untrusted_Python_script_safely_(i.e._Sandbox)

---
Bob the Hamster


Re: [pygame] Scripting language

2006-12-18 Thread Jakub Piotr Cłapa

Farai Aschwanden wrote:
Ok, as far as I understand now you want to let players changing their 
Avatars over a script language via Internet. Hmmm, nice feature letting 
players create their own scripts. Well, Im not a security guy but 
letting others use any (script) language that is technically able to 
access the directory structure of the system is risky. Whether its 
Python or any other not self written language you want to offer to you 
users I only see the following options:


- The user scripts are running on a exposed machine
- The user rights are strongly restricted
- The script language you offer to players is limited in its 
functionality (checking commands of players must be done then)


Maybe it already helps if you dont allow certain import functionalities 
(specially no direct disk access).


The problem is that disk access is a built-in in Python. And if you want 
to expose anything than you leave a way to go through your function to 
your module and than to anything you want. That's the reason why 
restricted execution was withdrawn from the stdlib. Nobody seems to care 
about security enught to handle this (rather difficult) problem.


--
regards,
Jakub Piotr Cłapa


Re: [pygame] Scripting language

2006-12-18 Thread robomancer

it seems safer to just use something
external and expose only the objects and methods I choose to allow.


This doesn't answer your original question, but I'll suggest it in
case it helps...

Perhaps you should look at something like Twisted's Perspective
Broker.  It's hard to wrap your head around, but it allows you to
declare certain data types and methods as "callable" by clients of a
server.  Then your scripting language can be Python, and the clients
can run whatever code they want (including removing their own home
directories if they really want to :P) but they can't run arbitrary
code on your server, only specific functions that you manually mark as
"ok" for remote clients to call.


Re: [pygame] Scripting language

2006-12-18 Thread Farai Aschwanden
Ok, as far as I understand now you want to let players changing their  
Avatars over a script language via Internet. Hmmm, nice feature  
letting players create their own scripts. Well, Im not a security guy  
but letting others use any (script) language that is technically able  
to access the directory structure of the system is risky. Whether its  
Python or any other not self written language you want to offer to  
you users I only see the following options:


- The user scripts are running on a exposed machine
- The user rights are strongly restricted
- The script language you offer to players is limited in its  
functionality (checking commands of players must be done then)


Maybe it already helps if you dont allow certain import  
functionalities (specially no direct disk access).


Greetings
Farai



Am 19.12.2006 um 00:05 schrieb Brandon N:


Hello Farai,
  I prefer to not dismiss Python as simply a scripting language. :p

  Anyway, I am using Python as the development language for both  
the client and server in a project I am working on. Now, I want to  
be able to expose certain functionality for scripting other than  
the internal development kind I have been doing with Python. That  
is, users can write scripts that affect the behavior of their  
avatars in the world.


  I do not want to expose Python itself (at least, the same  
environment that the server is running in) because it seems  
relatively easy to reach outside of one's module in Python to muck  
with internal settings. I certainly cannot check for every piece of  
unsafe code and users will not have the server source so as to  
easily engineer such a thing, but it seems safer to just use  
something external and expose only the objects and methods I choose  
to allow.


Thanks,
  Brandon


On Dec 18, 2006, at 5:51 PM, Farai Aschwanden wrote:


Hello Brandon

Maybe I missunderstand you but Python IS a scripting language.  
What is your intention using Python?


Farai


Am 18.12.2006 um 22:53 schrieb Brandon N:


Hello all,
  This is not strictly a pygame question though it does relate to  
my use of pygame in general. What have people used for scripting  
languages in Python? I suppose I could use Python itself but I do  
not want to expose anything through the use of eval or otherwise  
(currently I am doing just about this). While I do not want to  
write a language from scratch, I do have a simple Lisp  
implementation that I could expose.


If this is way too off-topic I'll try to find another place to ask.

Cheers,
  Brandon








Re: [pygame] Scripting language

2006-12-18 Thread JoN

Hate to say it but, really I'd say its best to use Python itself and implement
any protection you want by other means (eg. fiddling with properties).

Securing python code is something I've had a little look into, as I'm working on
something that allows pickled objects to launch pythreads, which opens up an
MSwindows like vista (sic) of virus vectors.

Generally when you've got an excellent scripting language already, and lets'
face it Python is the Best (:)), re-inventing the wheel is not something you
want to do!

Jon


Quoting Brandon N <[EMAIL PROTECTED]>:

> Hello all,
>This is not strictly a pygame question though it does relate to my  
> use of pygame in general. What have people used for scripting  
> languages in Python? I suppose I could use Python itself but I do not  
> want to expose anything through the use of eval or otherwise  
> (currently I am doing just about this). While I do not want to write  
> a language from scratch, I do have a simple Lisp implementation that  
> I could expose.
> 
> If this is way too off-topic I'll try to find another place to ask.
> 
> Cheers,
>Brandon
> 





Come and visit Web Prophets Website at http://www.webprophets.net.au



Re: [pygame] Scripting language

2006-12-18 Thread Brandon N

That is the sort of thing I do not want to expose.

(And that would remove the current users home directory.)

On Dec 18, 2006, at 6:02 PM, Luke Paireepinart wrote:


Patrick Mullen wrote:
I don't see how this is safer...
def make_ball_bounce(ball):
   import os
   os.system('rm -rf ~')

(I don't know what that does, since I am not on Linux.  I got it  
from http://mail.python.org/pipermail/python-list/2002-July/ 
155190.html ,

but I suspect it does something bad :))






Re: [pygame] Scripting language

2006-12-18 Thread Brandon N

Hello Farai,
  I prefer to not dismiss Python as simply a scripting language. :p

  Anyway, I am using Python as the development language for both the  
client and server in a project I am working on. Now, I want to be  
able to expose certain functionality for scripting other than the  
internal development kind I have been doing with Python. That is,  
users can write scripts that affect the behavior of their avatars in  
the world.


  I do not want to expose Python itself (at least, the same  
environment that the server is running in) because it seems  
relatively easy to reach outside of one's module in Python to muck  
with internal settings. I certainly cannot check for every piece of  
unsafe code and users will not have the server source so as to easily  
engineer such a thing, but it seems safer to just use something  
external and expose only the objects and methods I choose to allow.


Thanks,
  Brandon


On Dec 18, 2006, at 5:51 PM, Farai Aschwanden wrote:


Hello Brandon

Maybe I missunderstand you but Python IS a scripting language. What  
is your intention using Python?


Farai


Am 18.12.2006 um 22:53 schrieb Brandon N:


Hello all,
  This is not strictly a pygame question though it does relate to  
my use of pygame in general. What have people used for scripting  
languages in Python? I suppose I could use Python itself but I do  
not want to expose anything through the use of eval or otherwise  
(currently I am doing just about this). While I do not want to  
write a language from scratch, I do have a simple Lisp  
implementation that I could expose.


If this is way too off-topic I'll try to find another place to ask.

Cheers,
  Brandon






Re: [pygame] Scripting language

2006-12-18 Thread Luke Paireepinart

Patrick Mullen wrote:
You could use imports instead of eval for better use of python as the 
scripting language.


Scripts can be defined like so:

script.py
-
def make_ball_bounce(ball):
ball.addForce([0,0,1])
-

Then to hook it, you import script:

def addBall(x,y):
script = None
try:
import script
reload(script)  #Edit scripts while game is running!
except:
#handle import errors
object = Ball([x,y],"red")
for func in dir(script):
setattr(object,func,getattr(script,func))
return object

Now in the game code:
ball = addBall(2,6)
if key=="enter":
   ball.make_ball_bounce(ball)
-
Even safer and less hacky, you could just set object.script = script, 
and then call ball.script.make_ball_bounce(ball)

I don't see how this is safer...
def make_ball_bounce(ball):
   import os
   os.system('rm -rf ~')

(I don't know what that does, since I am not on Linux.  I got it from 
http://mail.python.org/pipermail/python-list/2002-July/155190.html ,

but I suspect it does something bad :))




Re: [pygame] Scripting language

2006-12-18 Thread Patrick Mullen

You could use imports instead of eval for better use of python as the
scripting language.

Scripts can be defined like so:

script.py
-
def make_ball_bounce(ball):
   ball.addForce([0,0,1])
-

Then to hook it, you import script:

def addBall(x,y):
   script = None
   try:
   import script
   reload(script)  #Edit scripts while game is running!
   except:
   #handle import errors
   object = Ball([x,y],"red")
   for func in dir(script):
   setattr(object,func,getattr(script,func))
   return object

Now in the game code:
ball = addBall(2,6)
if key=="enter":
  ball.make_ball_bounce(ball)
-
Even safer and less hacky, you could just set object.script = script, and
then call ball.script.make_ball_bounce(ball)

Not tested, but some form of this method should work.


Re: [pygame] Scripting language

2006-12-18 Thread Farai Aschwanden

Hello Brandon

Maybe I missunderstand you but Python IS a scripting language. What  
is your intention using Python?


Farai


Am 18.12.2006 um 22:53 schrieb Brandon N:


Hello all,
  This is not strictly a pygame question though it does relate to  
my use of pygame in general. What have people used for scripting  
languages in Python? I suppose I could use Python itself but I do  
not want to expose anything through the use of eval or otherwise  
(currently I am doing just about this). While I do not want to  
write a language from scratch, I do have a simple Lisp  
implementation that I could expose.


If this is way too off-topic I'll try to find another place to ask.

Cheers,
  Brandon




[pygame] Scripting language

2006-12-18 Thread Brandon N

Hello all,
  This is not strictly a pygame question though it does relate to my  
use of pygame in general. What have people used for scripting  
languages in Python? I suppose I could use Python itself but I do not  
want to expose anything through the use of eval or otherwise  
(currently I am doing just about this). While I do not want to write  
a language from scratch, I do have a simple Lisp implementation that  
I could expose.


If this is way too off-topic I'll try to find another place to ask.

Cheers,
  Brandon