Creating a capabilities-based restricted execution system

[Martin v. Loewis]

Re: Creating a capabilities-based restricted execution system

Sean R. Lynch wrote:[color=blue]
> Well, I'm providing a same_type function that compares types. What else
> do you want to do with type()? The other option is to go the Zope3 route
> and provide proxies to the type objects returned by type().[/color]

I don't know what is needed, but I know that existing code will break
when it did not strictly need to - no existing code uses your function.

If you think your users can accept rewriting their code - fine.

Regards,
Martin

[John Roth]

Re: Creating a capabilities-based restricted execution system


"Aahz" <aahz@pythoncra ft.com> wrote in message
news:bt7lbp$ovg $1@panix2.panix .com...[color=blue]
> In article <vveg0bb6is2f60 @news.supernews .com>,
> John Roth <newsgroups@jhr othjr.com> wrote:[color=green]
> >"Sean R. Lynch" <seanl@chaosrin g.org> wrote in message
> >news:9Jecnc6TZ dy4lGqiXTWc-w@speakeasy.net ...[color=darkred]
> >> John Roth wrote:
> >>>
> >>> Yes, you're missing something really obvious. Multi-level security
> >>> is a real difficult problem if you want to solve it in a believable
> >>> (that is, bullet-proof) fashion. The only way I know of solving it
> >>> is to provide separate execution environments for the different
> >>> privilege domains. In the current Python structure, that means
> >>> different interpreters so that the object structures don't intermix.
> >>
> >> Hmmm, can you give me an example of a Python application that works
> >> this way? Zope seems to be doing fine using RestrictedPytho n.
> >> RestrictedPytho n is, in fact, an attempt to provide different
> >> execution environments within the same memory space, which is the
> >> whole point of my exercise. Now, I know that the lack of an example
> >> of insecurity is not proof of security, but can you think of a way to
> >> escape from RestrictedPytho n's environment? DoS is still possible,
> >> but as I'm not planning on using this for completely untrusted users,
> >> I'm not too concerned about that.[/color]
> >
> >Restricted Python was withdrawn because of a number of holes, of which
> >new style classes were the last straw.[/color]
>
> RestrictedPytho n was *not* withdrawn; rexec was withdrawn. This is a
> difficult enough issue to discuss without confusing different modules.[/color]
See[color=blue]
>[/color]

http://dev.zope.org/Wikis/DevSite/Projects/SupportPython21/RestrictedPython

I'm not sure what you're trying to say. The Zope page you reference
says that they were (prior to 2.1) doing things like modifying generated
byte code and reworking the AST. That's fun stuff I'm sure, but it
doesn't have anything to do with "Restricted Execution" as defined in the
Python Library Reference, Chapter 17, which covers Restricted Execution,
RExec and Bastion (which was also withdrawn.)

If I confused you with a subtle nomenclature difference, sorry. I don't
care what Zope is doing or not doing, except for the fact that it seems
to come up in this discussion. I'm only concerned with what Python is
(or is not) doing. The approach in the Wiki page you pointed to does,
however, seem to be a substantially more bullet-proof approach than
Python's Restricted Execution.

John Roth
[color=blue]
> --
> Aahz (aahz@pythoncra ft.com) <*>[/color]
http://www.pythoncraft.com/[color=blue]
>
> Weinberg's Second Law: If builders built buildings the way programmers[/color]
wrote[color=blue]
> programs, then the first woodpecker that came along would destroy[/color]
civilization.

[Sean R. Lynch]

Re: Creating a capabilities-based restricted execution system

Serge Orlov wrote:[color=blue]
> You're right, the wording is not quite correct. My point was that it should
> take effort to make attributes _public_, for example, going to another
> source line and typing attribute name or doing whatever "declaratio n" means.
> This way adding new attribute or leaking "unsecured" object will
> raise an exception when untrusted code will try to access it. Otherwise
> one day something similar to rexec failure will happen: somebody
> added __class__ and __subclasses__ attributes and rexec blindly
> allowed to access them. The leading underscore doesn't matter, it
> could be name like encode/decode that is troublesome.
>
> By the way, my code above is buggy, it's a good idea that you're
> not going to use it :) Let me try it the second time in English words:
> If the attribute 'attr' is declared public give it. If the function with
> UUID has access to attribute 'attr' on object 'obj' give it. Otherwise fail.[/color]

Ok, I think you've pretty much convinced me here. My choices for
protected attributes were to either name them specially and only allow
those attribute accesses on the name "self" (which I treat specially),
or to make everything protected by default, pass all attribute access
through a checker function (which I was hoping to avoid), and check for
a special attribute to define which attributes are supposed to be
public. Do you think it's good enough to make all attributes protected
as opposed to private by default?
[color=blue]
> Nevermind, it's just a scary word :) It can concern you if you worry
> about information leaking from one security domain to another. Like
> prisoners knocking the wall to pass information between them. In
> computers it may look like two plugins, one is processing credit
> cards and the other one has capability to make network connections.
> If they are written by one evil programmer the first one can "knock
> the wall" to pass the information to the second. "knocking the wall"
> can be encoded like quick memory allocation up to failure = 1, no
> quick memory allocation = 0. Add error correction and check summing
> and you've got a reliable leak channel.[/color]

Hmmm, I think this would be even more difficult to protect from than
doing resource checks. Fortunately, I'm not planning on processing any
credit cards with this code. The primary purpose is so that multiple
programmers (possibly thousands) can work in the same memory space
without stepping on one another.
[color=blue]
> I'm not sure how to deal with str.encode too. You don't know what
> kind of codecs are registered for that method for sure, one day there
> could be registered an unknown codec that does something unknown.
> Shouldn't you have two (or several) codecs.py modules(instanc es?)
> for trusted and untrusted code? And str.encode should be transparently
> redirected to the proper one?[/color]

I guess I'll just make attributes protected by default, and force the
programmer to go out of their way to make things public. Then I can use
the Zope/RestrictedPytho n technique of assuming everything is insecure
until proven otherwise, and only expose parts of the interface on
built-in types that have been audited.

Thank you very much for your extremely informative responses!

[Aahz]

Re: Creating a capabilities-based restricted execution system

In article <vveohcpod4oje0 @news.supernews .com>,
John Roth <newsgroups@jhr othjr.com> wrote:[color=blue]
>"Aahz" <aahz@pythoncra ft.com> wrote in message
>news:bt7lbp$ov g$1@panix2.pani x.com...[color=green]
>> In article <vveg0bb6is2f60 @news.supernews .com>,
>> John Roth <newsgroups@jhr othjr.com> wrote:[color=darkred]
>>>
>>>Restricted Python was withdrawn because of a number of holes, of which
>>>new style classes were the last straw.[/color]
>>
>> RestrictedPytho n was *not* withdrawn; rexec was withdrawn. This is a
>> difficult enough issue to discuss without confusing different modules. See
>> http://dev.zope.org/Wikis/DevSite/Pr...strictedPython[/color]
>
>I'm not sure what you're trying to say. The Zope page you reference
>says that they were (prior to 2.1) doing things like modifying generated
>byte code and reworking the AST. That's fun stuff I'm sure, but it
>doesn't have anything to do with "Restricted Execution" as defined in the
>Python Library Reference, Chapter 17, which covers Restricted Execution,
>RExec and Bastion (which was also withdrawn.)
>
>If I confused you with a subtle nomenclature difference, sorry. I don't
>care what Zope is doing or not doing, except for the fact that it seems
>to come up in this discussion. I'm only concerned with what Python is
>(or is not) doing. The approach in the Wiki page you pointed to does,
>however, seem to be a substantially more bullet-proof approach than
>Python's Restricted Execution.[/color]

Well, I don't care what you do or don't care about, but I do care that
if you're going to post in a thread that you actually read what you're
responding to and that you post accurate information. If you go back to
the post that started this thread, it's quite clear that the reference
was specifically to Zope's RestrictedPytho n.
--
Aahz (aahz@pythoncra ft.com) <*> http://www.pythoncraft.com/

Weinberg's Second Law: If builders built buildings the way programmers wrote
programs, then the first woodpecker that came along would destroy civilization.

[John Roth]

Re: Creating a capabilities-based restricted execution system


"Aahz" <aahz@pythoncra ft.com> wrote in message
news:bt82d7$ort $1@panix3.panix .com...[color=blue]
> In article <vveohcpod4oje0 @news.supernews .com>,
> John Roth <newsgroups@jhr othjr.com> wrote:[color=green]
> >"Aahz" <aahz@pythoncra ft.com> wrote in message
> >news:bt7lbp$ov g$1@panix2.pani x.com...[color=darkred]
> >> In article <vveg0bb6is2f60 @news.supernews .com>,
> >> John Roth <newsgroups@jhr othjr.com> wrote:
> >>>
> >>>Restricted Python was withdrawn because of a number of holes, of which
> >>>new style classes were the last straw.
> >>
> >> RestrictedPytho n was *not* withdrawn; rexec was withdrawn. This is a
> >> difficult enough issue to discuss without confusing different modules.[/color][/color][/color]
See[color=blue][color=green][color=darkred]
> >>[/color][/color][/color]
http://dev.zope.org/Wikis/DevSite/Pr...strictedPython[color=blue][color=green]
> >
> >I'm not sure what you're trying to say. The Zope page you reference
> >says that they were (prior to 2.1) doing things like modifying generated
> >byte code and reworking the AST. That's fun stuff I'm sure, but it
> >doesn't have anything to do with "Restricted Execution" as defined in the
> >Python Library Reference, Chapter 17, which covers Restricted Execution,
> >RExec and Bastion (which was also withdrawn.)
> >
> >If I confused you with a subtle nomenclature difference, sorry. I don't
> >care what Zope is doing or not doing, except for the fact that it seems
> >to come up in this discussion. I'm only concerned with what Python is
> >(or is not) doing. The approach in the Wiki page you pointed to does,
> >however, seem to be a substantially more bullet-proof approach than
> >Python's Restricted Execution.[/color]
>
> Well, I don't care what you do or don't care about, but I do care that
> if you're going to post in a thread that you actually read what you're
> responding to and that you post accurate information. If you go back to
> the post that started this thread, it's quite clear that the reference
> was specifically to Zope's RestrictedPytho n.[/color]

I beg to differ. That's what the OP said he started with, not what he's
mostly interested in nor where he wants to end up. I'm including
the first paragraph below:

[extract from message at head of thread]
I've been playing around with Zope's RestrictedPytho n, and I think I'm
on the way to making the modifications necessary to create a
capabilities-based restricted execution system. The idea is to strip out
any part of RestrictedPytho n that's not necessary for doing capabilities
and do all security using just capabilities.
[end extract]

To me, at least, it's clear that while he's *started* with a consideration
of Zope's RestrictedPytho n, he's talking about what would be needed
in regular Python. If he was focusing on Zope, this is the wrong forum
for the thread.

My fast scan of Zope yesterday showed that it was quite impressive,
but some of the things they did seem to be quite specific to the Zope
environment, and don't seem (at least to me) to be all that applicable
to a general solution to having some form of restricted execution.

Much of this thread has focused on "capabiliti es" and the use of
proxies to implement capabilities. AFIAC, that's not only putting
attention on mechanism before policy, but it's putting attention on
mechanism in the wrong place.

What I *haven't* seen in this thread is very much consideration of
what people want from a security implementation. I've seen that in
some other threads, which included some ways of taming exec and
eval when all you want is a data structure that contains nothing but
known kinds of objects. You don't, however, need exec and eval
for that if you're willing to use the compiler tools (and, I presume,
take a substantial performance hit.)

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()."

John Roth
[color=blue]
> --
> Aahz (aahz@pythoncra ft.com) <*>[/color]
http://www.pythoncraft.com/[color=blue]
>
> Weinberg's Second Law: If builders built buildings the way programmers[/color]
wrote[color=blue]
> programs, then the first woodpecker that came along would destroy[/color]
civilization.

Have to be a pretty non-aggressive woodpecker, if it allowed something
that extensive and complicated to happen before attacking it.

[Serge Orlov]

Re: Creating a capabilities-based restricted execution system


"John Roth" <newsgroups@jhr othjr.com> wrote in message news:vvg0h93ue6 3c0b@news.super news.com...[color=blue]
>
> Much of this thread has focused on "capabiliti es" and the use of
> proxies to implement capabilities. AFIAC, that's not only putting
> attention on mechanism before policy, but it's putting attention on
> mechanism in the wrong place.[/color]

I'm not sure why it should be discussed here since Sean refered
to E in the first post (http://www.erights.org/), so I think he's
comfortable with the policy defined by E? I think he has
missed the part that implementation should help as much as
it can prevent leaking capabilities from one security domain to
another. I pointed to that already.
[color=blue]
>
> What I *haven't* seen in this thread is very much consideration of
> what people want from a security implementation.[/color]

I think Sean is talking about his own implementation. I didn't
see anywhere he said he's going to write general implementation
for other people. He said what he wants from his implementation.
[color=blue]
> 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()."[/color]

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...)

-- Serge.

[Serge Orlov]

Re: Creating a capabilities-based restricted execution system


"Sean R. Lynch" <seanl@chaosrin g.org> wrote in message news:srudnTjvU9 BOH2qiRVn-uA@speakeasy.ne t...[color=blue]
> Ok, I think you've pretty much convinced me here. My choices for
> protected attributes were to either name them specially and only allow
> those attribute accesses on the name "self" (which I treat specially),
> or to make everything protected by default, pass all attribute access
> through a checker function (which I was hoping to avoid), and check for
> a special attribute to define which attributes are supposed to be
> public. Do you think it's good enough to make all attributes protected
> as opposed to private by default?[/color]

Are you talking about C++ like protected fields and methods? What if
untrusted code subclasses your proxy object?
[color=blue][color=green]
> > I'm not sure how to deal with str.encode too. You don't know what
> > kind of codecs are registered for that method for sure, one day there
> > could be registered an unknown codec that does something unknown.
> > Shouldn't you have two (or several) codecs.py modules(instanc es?)
> > for trusted and untrusted code? And str.encode should be transparently
> > redirected to the proper one?[/color]
>
> I guess I'll just make attributes protected by default, and force the
> programmer to go out of their way to make things public. Then I can use
> the Zope/RestrictedPytho n technique of assuming everything is insecure
> until proven otherwise, and only expose parts of the interface on
> built-in types that have been audited.[/color]

Thinking about str.encode I conviced myself that global state shouldn't
be shared by different security domains so that means codecs.py and
__builtins__ must be imported into each security domain separately.
It's pretty easy to do with codecs.py since it's python code. But importing
__builtins__ more than once is pretty hard since it wasn't designed
for that.

-- Serge.

[Sean R. Lynch]

Re: Creating a capabilities-based restricted execution system

Serge Orlov wrote:[color=blue]
> "John Roth" <newsgroups@jhr othjr.com> wrote in message news:vvg0h93ue6 3c0b@news.super news.com...
>[color=green]
>>Much of this thread has focused on "capabiliti es" and the use of
>>proxies to implement capabilities. AFIAC, that's not only putting
>>attention on mechanism before policy, but it's putting attention on
>>mechanism in the wrong place.[/color]
>
>
> I'm not sure why it should be discussed here since Sean refered
> to E in the first post (http://www.erights.org/), so I think he's
> comfortable with the policy defined by E? I think he has
> missed the part that implementation should help as much as
> it can prevent leaking capabilities from one security domain to
> another. I pointed to that already.[/color]

I am comfortable (so far) with the policy defined by E. However, I've
been learning more about that policy as I go, including the necessity of
helping the programmer prevent leaks, which I've started to implement by
making objects completely opaque by default and requiring that classes
list attributes that they want to make public. I have kept my
name-mangling scheme for private attributes. I'm working on making
classes opaque while still allowing code to call methods defined on
superclasses but only on self, not on other objects that happen to
inherit from the same superclass.
[color=blue][color=green]
>>What I *haven't* seen in this thread is very much consideration of
>>what people want from a security implementation.[/color]
>
>
> I think Sean is talking about his own implementation. I didn't
> see anywhere he said he's going to write general implementation
> for other people. He said what he wants from his implementation.[/color]

I would like my implementation to be as general as possible, but I'm
writing it for my own projects. All this talk of "breaking existing
code" and the like is not particularly relevant to me because, while I'd
like code to look as much like regular Python as possible, it's simply
not possible not to break existing code while helping the programmer
prevent leaks. Making objects opaque by default is going to break a hell
of a lot more code than not having a type() builtin, so I think people
can see why I'm not too concerned about leaving various builtins out.
[color=blue][color=green]
>>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()."[/color][/color]

This is an interesting problem, but not one I'm trying to solve here.
I'm modifying RestrictedPytho n to make it possible to use a pure
capabilities-based security model in an application server. The
application server must scale to tens of thousands of security domains,
and I see no reason why the security model can't or shouldn't be
language-based instead of OS-based. There's E for Java, why can't we
make something similar for Python? There is nothing particularly special
about Java that makes it more suitable for E than Python is. Both have
unforgeable references. I've already added object encapsulation. I'm
working on eliminating any static mutable state.

Ultimately, I'd like to have user-level threads, too. I'm considering
either using Stackless for this or doing some mangling of ASTs to make
it easier to use generators as coroutines. Unfortunately, I can't think
of a way for the compiler to tell that you're calling a coroutine from
within a coroutine and therefore needs to output "yield (locals,
resultvarname, func, args, kwargs)" instead of a regular function call
without using some special syntax. Actually, I don't even know if it's
possible to modify the locals dict of a running generator without
causing trouble.

[Sean R. Lynch]

Re: Creating a capabilities-based restricted execution system

Serge Orlov wrote:[color=blue]
> "Sean R. Lynch" <seanl@chaosrin g.org> wrote in message news:srudnTjvU9 BOH2qiRVn-uA@speakeasy.ne t...
>[color=green]
>>Ok, I think you've pretty much convinced me here. My choices for
>>protected attributes were to either name them specially and only allow
>>those attribute accesses on the name "self" (which I treat specially),
>>or to make everything protected by default, pass all attribute access
>>through a checker function (which I was hoping to avoid), and check for
>>a special attribute to define which attributes are supposed to be
>>public. Do you think it's good enough to make all attributes protected
>>as opposed to private by default?[/color]
>
>
> Are you talking about C++ like protected fields and methods? What if
> untrusted code subclasses your proxy object?[/color]

Hmmm. I was thinking you'd trust those you were allowing to subclass
your classes a bit more than you'd trust people to whom you'd only give
instances, but now that you mention it, you're right. I should make all
attributes fully private by default, requiring the progammer to declare
both protected and public attributes, and I should make attributes only
writable by the class on which they're declared. I guess I also need to
make it impossible to override any attribute unless it's declared OK to
do so.

I wonder if each of these things can be done with capabilities? A
reference to a class is basically the capability to subclass it. I could
create a concept of "slots" as well. This would require a change in
syntax, however; you'd be calling setter(obj, value) and getter(obj),
and this isn't really something I could cover up in the compiler. I
think I'll forget about this for now because E just uses Java's own
object encapsulation, so I guess I should just stick with creating
Java-like object encapsulation in Python.

I need to implement a callsuper() function as well, because I don't want
to be giving programmers access to unbound methods.
[color=blue]
> Thinking about str.encode I conviced myself that global state shouldn't
> be shared by different security domains so that means codecs.py and
> __builtins__ must be imported into each security domain separately.
> It's pretty easy to do with codecs.py since it's python code. But importing
> __builtins__ more than once is pretty hard since it wasn't designed
> for that.[/color]

Global *mutable* state shouldn't be shared, AFAICT. I believing making
sure no mutable state is reachable through __builtins__ and having a new
globals dict for each security domain should be enough. Any modules that
are imported would need to be imported separately for each domain, which
should be possible with a modified __import__ builtin. I don't have any
intention of allowing import of unaudited C modules.

[John Roth]

Re: Creating a capabilities-based restricted execution system


"Serge Orlov" <sombDELETE@pob ox.ru> wrote in message
news:bta2ng$16v 7$1@nadya.doma. ..[color=blue]
>
> "John Roth" <newsgroups@jhr othjr.com> wrote in message[/color]
news:vvg0h93ue6 3c0b@news.super news.com...[color=blue][color=green]
> >
> > What I *haven't* seen in this thread is very much consideration of
> > what people want from a security implementation.[/color]
>
> I think Sean is talking about his own implementation. I didn't
> see anywhere he said he's going to write general implementation
> for other people. He said what he wants from his implementation.[/color]

I see that point, and now that it's been made explicit (I missed
it the first time around, sorry,) I'm ok with it.
[color=blue][color=green]
> > 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()."[/color]
>
> 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...)[/color]

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.

John Roth[color=blue]
>
> -- Serge.
>
>[/color]

[Serge Orlov]

Re: Creating a capabilities-based restricted execution system


"Sean R. Lynch" <seanl@chaosrin g.org> wrote in message news:mvScnSDrma 66AWWiXTWc-g@speakeasy.net ...[color=blue]
> Serge Orlov wrote:[color=green]
> > "Sean R. Lynch" <seanl@chaosrin g.org> wrote in message news:srudnTjvU9 BOH2qiRVn-uA@speakeasy.ne t...
> >
> > Thinking about str.encode I conviced myself that global state shouldn't
> > be shared by different security domains so that means codecs.py and
> > __builtins__ must be imported into each security domain separately.
> > It's pretty easy to do with codecs.py since it's python code. But importing
> > __builtins__ more than once is pretty hard since it wasn't designed
> > for that.[/color]
>
> Global *mutable* state shouldn't be shared, AFAICT.[/color]

Right, I missed this simple rule. My mind is still confined by my recent
attempt to add security by only translating bytecode without any changes
to the interpreter.
[color=blue]
> I believing making
> sure no mutable state is reachable through __builtins__[/color]

Are you going to create multiple __builtins__ or you're just going
to get rid of any global objects in __builtins__? The first lets you
handle str.encode the right way.
[color=blue]
> and having a new
> globals dict for each security domain should be enough. Any modules that
> are imported would need to be imported separately for each domain,[/color]

Can C modules be imported more than once in CPython?
[color=blue]
> which
> should be possible with a modified __import__ builtin. I don't have any
> intention of allowing import of unaudited C modules.[/color]

Agreed.

-- Serge.

[Serge Orlov]

Re: Creating a capabilities-based restricted execution system


"John Roth" <newsgroups@jhr othjr.com> wrote in message news:vvh75ienj7 g244@news.super news.com...[color=blue]
>
> "Serge Orlov" <sombDELETE@pob ox.ru> wrote in message
> news:bta2ng$16v 7$1@nadya.doma. ..[color=green]
> >
> > "John Roth" <newsgroups@jhr othjr.com> wrote in message[/color]
> news:vvg0h93ue6 3c0b@news.super news.com...[color=green][color=darkred]
> > >
> > > 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()."[/color]
> >
> > 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...)[/color]
>
> 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.[/color]

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.

[John Roth]

Re: Creating a capabilities-based restricted execution system


"Serge Orlov" <sombDELETE@pob ox.ru> wrote in message
news:btac4k$1ek r$1@nadya.doma. ..[color=blue]
>
> "John Roth" <newsgroups@jhr othjr.com> wrote in message[/color]
news:vvh75ienj7 g244@news.super news.com...[color=blue][color=green]
> >
> > "Serge Orlov" <sombDELETE@pob ox.ru> wrote in message
> > news:bta2ng$16v 7$1@nadya.doma. ..[color=darkred]
> > >
> > > "John Roth" <newsgroups@jhr othjr.com> wrote in message[/color]
> > news:vvg0h93ue6 3c0b@news.super news.com...[color=darkred]
> > > >
> > > > 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...)[/color]
> >
> > 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.[/color]
>
> 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.[/color]

Sean Ross took a pass at this idea in the thread
"Finding File Size" starting on 1/1. That got renamed
to "Filename Type" somewhere fairly quick.

There's now a pre-pep http://tinyurl.com/2578q
for the notion, thanks to Gerrit Holl.

John Roth[color=blue]
>
>[/color]

[Sean R. Lynch]

Re: Creating a capabilities-based restricted execution system

Serge Orlov wrote:[color=blue]
> "Sean R. Lynch" <seanl@chaosrin g.org> wrote in message news:mvScnSDrma 66AWWiXTWc-g@speakeasy.net ...[color=green]
>>
>>Global *mutable* state shouldn't be shared, AFAICT.[/color]
>
>
> Right, I missed this simple rule. My mind is still confined by my recent
> attempt to add security by only translating bytecode without any changes
> to the interpreter.[/color]

You were translating bytecode rather than working with ASTs? That would
be hard to maintain, considering that Zope found it too difficult to
maintain even manipulating concrete syntax trees. Also, I don't really
consider that I'm modifying the interpreter, I'm just giving the
interpreter a different globals dict.
[color=blue][color=green]
>>I believing making
>>sure no mutable state is reachable through __builtins__[/color]
>
>
> Are you going to create multiple __builtins__ or you're just going
> to get rid of any global objects in __builtins__? The first lets you
> handle str.encode the right way.[/color]

I'm not sure what you mean by this. I'm creating a dict for
__builtins__, but AFAIK it's not possible for code to modify the
__builtins__ dict other than through the name __builtins__, which starts
with an underscore and so is invalid. All of the objects I have in
__builtins__ right now are immutable within the restricted environment
because they're either functions or classes.

Python modules that are imported in the restricted environment will be
read-only and each domain will get its own copy. This should prevent
leaks caused by two domains importing the same module and then
performing operations that affect the state of the module. Modules will
need to explicitly specify what names they want to export the same way
classes do in order to prevent inadvertent leaks.
[color=blue][color=green]
>>and having a new
>>globals dict for each security domain should be enough. Any modules that
>>are imported would need to be imported separately for each domain,[/color]
>
>
> Can C modules be imported more than once in CPython?[/color]

Not that I'm aware of, which is why they will need to be audited for
mutable state and other sources of leaks and excess privilege. C modules
that we need that have problems will get proxies the same way E has
proxies for Swing.

[Sean R. Lynch]

Re: Creating a capabilities-based restricted execution system

I put up a page on my Wiki with what I can remember off the top of my
head of what we've discussed so far and some of what I've implemented so
far (though my implementation is in flux). It's at
<http://wiki.literati.o rg/CapablePython>. Feel free to add comments.