[Tutor] trusted?

[Neal McBurnett]

One of the strengths of Python (and other modern languages) is that it
protects users from themselves.  E.g. automated storage management and
garbage collection prevents programs from stomping on themselves via
untyped pointers.

Similarly with operating systems, they (sometimes) protect the
hardware layer and kernel structures from flawed or evil unprivileged
programs at the application layer, and protect one program or user
from another.

The concepts of "tainted" input information (perl) or untrusted
applets (Java) or active content (safe-tcl) are a further extension of
these principles, and the pointers at

  http://cap-lore.com/Dual.html

provide more info on each of those.

At one level this can be described as a "coding problem".  But the way
I view it, languages and libraries and systems can make safe
development easier or make "firewalls" (in a generic sense) more
effective.  I'm all for it, whether it is saving me from my own
mistakes, or mistakes of the folks that write software I use by
choice, or from malicious intents of nasty people out there.

The restricted execution problem is pretty hard, and is relatively
"all or nothing" since it is often designed to protect systems from
general-purpose deliberate attack by untrusted agents.  So I
understand people being leery of working on it without enough buyin to
do it right.

But the "taint" problem seems more approachable, since the threat is
more constrained and partial solutions can help.  The programmer is
taking strings from web forms, environment variables, and other
"untrusted sources" and using them to design queries for databases, or
to put together a string for os.system().  If a user the Internet puts
something like "; rm -rf /" in a string, and you embed that string in
a system call, the semicolon can cause the shell to run the "rm"
command and do damage.

A facility like "taint" can help a programmer avoid this sort of
problem, and it seems like handling the most common cases wouldn't be
all that hard, even if less frequent cases were still not taken care
of.

I know I didn't make that very clear, so again, see
 http://sourceforge.net/tracker/index.php?func=detail&aid=500698&group_id=5470&atid=355470
for the details.

Neal McBurnett                 http://bcn.boulder.co.us/~neal/
Signed and/or sealed mail encouraged.  GPG/PGP Keyid: 2C9EBA60


On Wed, Jun 18, 2003 at 12:49:04PM -0700, Neil Schemenauer wrote:
> Gerardo Arnaez wrote:
> > --- Neil Schemenauer <nas-pytut@python.ca> wrote:
> > > Python will indeed no longer pretend to support
> > > restricted execution.
> > 
> > Is this really a problem with the language 
> > isnt this more of a coding problem? ie code to make it
> > secure?
> 
> Many problems could be called a coding problem. :-)
> 
> Seriously, it is both a lanuage and a coding problem.  The specification
> of what restricted execution means is not clear.  The implemention of
> restricted execution was also not correct.  As I said in my last email,
> the Python developers don't have the resource to fix these problems.