Creating a capabilities-based restricted execution system

Serge Orlov sombDELETE at
Mon Jan 5 01:46:16 CET 2004

"John Roth" <newsgroups at> wrote in message news:vvh75ienj7g244 at
> "Serge Orlov" <sombDELETE at> wrote in message
> news:bta2ng$16v7$1 at nadya.doma...
> >
> > "John Roth" <newsgroups at> wrote in message
> news:vvg0h93ue63c0b at
> > >
> > > One problem I've been playing around with is: how would you
> > > implement something functionally equivalent to the Unix/Linux
> > > chroot() facility? The boundaries are that it should not require
> > > coding changes to the application that is being restricted, and it
> > > should allow any and all Python extension (not C language
> > > extension) to operate as coded (at least as long as they don't
> > > try to escape the jail!) Oh, yes. It has to work on Windows,
> > > so it's not a legitimate response to say: "use chroot()."
> >
> > I don't see any unsolvable problems. Could you be more specific
> > what is the problem? (besides time, money, need to support
> > alternative python implementation, etc...)
> Well, I don't see any unsolvable problems either. The biggest
> sticking point is that the Unices use hard links to create
> a directory tree that has the necessary programs availible.
> Windows does not have this capability, so an implementation
> would have to build a virtual directory structure, intercept all
> paths and map them to the virtual structure backwards and
> forwards.
> The reason I find it an interesting problem is that I can't see
> any way to do it with the kind of "generic" facility that was
> in the Python Restricted execution facility,  at least without a
> complete redesign of the file and directory functions and
> classes in the os module. Without that, it would
> require code in the C language implementation modules.
> Right now the file and directory management modules are a
> real mess.

Right, you can do it with a custom importer and wrapper
functions over all file and directory functions. But that's
a mess over a mess and any mess is *bad* for security.
The way out the mess is probably filepath object that
should consolidate all access to files and directories.
If you wanted to make a point that std library should
be designed with security in mind I agree with you.
One step in that direction is to design everything OO.
OO design plays nice with capabilities.

-- Serge.

More information about the Python-list mailing list