Creating a capabilities-based restricted execution system

[Serge Orlov]

"Sean R. Lynch" <seanl at chaosring.org> wrote in message news:d7ycncKp5rket2qiXTWc-g at speakeasy.net...
> Serge Orlov wrote:
> > "Sean R. Lynch" <seanl at chaosring.org> wrote in message news:LmmdnUn4seDeGWuiXTWc-w at speakeasy.net...
> >>To create private attributes, I'm using "name mangling," where names
> >>beginning with X_ within a class definition get changed to
> >>_<uuid>_<name>, where the UUID is the same for that class. The UUIDs
> >>don't need to be secure because it's not actually possible to create
> >>your own name starting with an underscore in RestrictedPython; they just
> >>need to be unique across all compiler invocations.
> >
> >
> > This is a problem: you declare private attributes whereas you should be
> > declaring public attributes and consider all other attributes private. Otherwise
> > you don't help prevent leakage. What about doing it this way:
> >
> > obj.attr means xgetattr(obj,acc_tuple) where acc_tuple = ('attr',UUID)
> > and xgetattr is
> > def xgetattr(obj,acc_tuple):
> >   if not has_key(obj.__accdict__,acc_tuple):
> >     raise AccessException
> >   return getattr(obj,acc_tuple[0])
> >
> > __accdict__ is populated at the time class or its subclasses are created.
> > If an object without __accdict__ is passed to untrusted code it will
> > just fail. If new attributes are introduced but not declared in __accdict__
> > they are also unreachable by default.
>
> This is very interesting, and you may convince me to use something
> similar, but I don't think you're quite correct in saying that the
> name-mangling scheme declares private attributes; what is the difference
> between saying "not having X_ in front of the attribute makes it public"
> and "having X_ in front of the attribute makes it private?"

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 "declaration" 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.


>
> I am not (particularly) concerned about DoS because I don't plan to be
> running anonymous code and having to restart the server isn't that big
> of a deal. I do plan to make it hard to accidentally DoS the server, but
> I'm not going to sacrifice a bunch of performance for that purpose. As
> for covert channels, can you give me an example of what to look for?

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.

>
> I am certainly worried about non-obvious things, but my intent wasn't to
> put up a straw man, because if I ask if I'm missing non-obvious things,
> the only possible answer is "of course."
>
> > By the way, did you think about str.encode? Or you are not worried about
> > bugs in zlib too?
>
> Well, it'll only take *one* problem of that nature to force me to go
> back to converting all attribute accesses to function calls. On the
> other hand, as long as any problem that allows a user to access
> protected data is actually a in (zlib, etc), I think I'm not going to
> worry about it too much yet. If there is some method somewhere that will
> allow a user access to protected data that is not considered a bug in
> that particular subsystem, then I have to fix it in my scheme, which
> would probably require going back to converting attribute access to
> method calls.

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(instances?)
for trusted and untrusted code? And str.encode should be transparently
redirected to the proper one?

-- Serge.