rexec questions

[Alex Martelli]

"Roman Suzi" <rnd at onego.ru> wrote in message
news:mailman.997215701.1431.python-list at python.org...
    ...
> getting malicious code. I read somewhere in some review on the Net that
> there need be hardcoded trust-based software execution model with
> well-defined bondaries what can do what.

As long as it's configurable...:-).

> rexec is very good model of it
> albeit inside Python world. Only network side is lacking...

Sorry, I don't agree: an untrusted code, by default in rexec,
is allowed to open ANY file for reading (and none for writing).

The 'none for writing' may be a bit too strict, but OK, on
some boxes that may be the only way to avoid a nasty program
filling up your disk (I'd rather be able to specify some
/tmp/sandbox path on which untrusted code can open files for
writing, with a quota of maximum size -- but that may be
impractical on some boxes, so a 'limited file-like object'
might be supplied by an overridden built-in open, etc).

But the 'all for reading' looks too wide to me -- untrusted
code might be able to get secrets from any file, and maybe
steganograph them into whatever kind of output it's doing,
so that some perp can get at them.  It's absolutely crucial
that openable files be restricted to specified paths, and
rexec by default doesn't provide this -- so you do have to
customize rexec by subclassing and overriding if you're
serious about not trusting untrusted code:-).

I agree (from what I recall, from back when I was writing
Java applets - it HAS been a long time!) that Java applet
security is TOO strict (e.g., no file reading at all --
that's erring on the side of caution).  But I do not agree
that rexec's only lack of easy, necessary customizability
is in its network operations.


Alex