[Python-Dev] Re: Whither rexec?

[Kevin Jacobs]

On Wed, 8 Jan 2003, "Martin v. L=F6wis" wrote:
> Kevin Jacobs wrote:
> >   It has been said that the previous rexec functionality was ad hoc a=
nd
> >   brittle, and many better solutions are possible.  What better alter=
natives
> >   exist in terms of features offered, overall runtime performance, ea=
se of
> >   maintenance, and validation?
>=20
> I disagree with that statement. The approach taken by rexec is very=20
> straight forward, and, in principle, allows to impose arbitrary=20
> functional restrictions on untrusted code.

Good.  I only partly agree with it myself.  However, rexec _is_ brittle, =
as
demonstrated by the many incremental problems that keep popping up, even
pre-Python 2.2.

> So anybody working on this should see how rexec could be enhanced. IMO,=
=20
> of course.

I agree, though seeing how it can be fixed is not the same as deciding th=
at
it is the optimal solution.  I'm starting out with a very open mind and a=
m
purposely solicting for as much input as possible.

> >   Proxy objects              -- making unsafe objects safe(r)
[...]
> >   Restricted introspection   -- limiting the amount of information
> >                                 obtainable from exposed objects and
> >                                 environment
>=20
> Can somebody please explain how this is different from restricted=20
> environments? I.e. why would one restrict introspection in general, as=20
> long as you can't obtain information about the system?

The closure of all objects reachable (via introspection) from
a given starting set can be _very_ large and non-trivial to compute.=20
Limiting introspection is a simple way to close many of possible holes
through which references to untrusted objects can be obtained.

> >   Tainting                   -- tracking trusted status of objects
>=20
> This is clearly out of scope of rexec, and, IMO, not relevant for=20
> untrusted code. Tainting is about processing untrusted data by trusted =
code.

I don't think it is so clearly out of the scope of the space of all possi=
ble
restricted execution enviornments.  Tainting (used in a fairly liberal
sense) is one way to propogate the security status of objects without hav=
ing
to proxy them.

> >   Security policy management -- Configuration of how security mechani=
sms are
> >                                 applied
>=20
> I think rexec is quite flexible here, giving or denying access on a=20
> per-function basis (and allowing to provide wrappers for functions whic=
h=20
> must be restricted depending on the set of arguments).

I agree.

Thanks for your input,
-Kevin

--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com