Secur(e/ing) Python?

May 30th, 2007 § 1 comment

I was read­ing over some of the new(er) com­ments on the Bugzilla Lan­guage com­ments page and one of them caught my eye:

Zope 3 indeed has zope.security (soon com­ing as an egg near you :). README.txt, code, svn co svn://svn.zope.org/repos/main/zope.security/trunk zope.security) — faassen

Read­ing that reminded me of Brett Cannon’s work around secur­ing the inter­preter.

Restricted access / sand box­ing is some­thing I’d love to poke around in (one day, the amount of things I want to work on is grow­ing) — the OLPC uses the very nice Bit­frost model for it’s secu­rity “plat­form” and hav­ing some­thing eas­ily access/leveraged within the Python inter­preter land­scape for secure python appli­ca­tion imple­men­ta­tion would be great.

You can see some of Brett’s addi­tional work here:Python secu­rity paper online and Rethink­ing Imports

Here’s a cool ASPN recipe too: Restricted “safe” eval.

I highly rec­om­mend peo­ple look at the new Zope stuff and Brett’s work, I’ll be fresh­en­ing my python src tree dump and try com­pil­ing it one of these days.

  • Mar­tijn Faassen

    The Zope secu­rity work isn’t new. It’s been part of Zope 3 for a few years now and has been used in pro­duc­tion settings.

What's this?

You are currently reading Secur(e/ing) Python? at jessenoller.com.

meta