would be nice: import from archive

[Alex Martelli]

Benjamin Niemann <pink at odahoda.de> wrote:
   ...
> Isn't the purpose of signatures that the importing program can trust the
> module? If it's implemented as you suggest, an attacker could just 
> inject path to an unsigned module into PYTHONPATH to fool a program. How

If the attacker is able to alter sys.path then it does not matter
whether zipfiles are even considered -- the attacker could simply
position a .pyc file early on the path.

> about something like
> 
> require_signature('mymodule')
> import mymodule

This could be made to work, but only if _every_ module was so checked
before importing it; otherwise, even just one unchecked module could
easily subvert __import__ or other aspects of the import hook mechanism.

So, if you're considering this approach, it makes more sense to switch
on module checking globally in an early phase of Python's startup
(because Python starts importing modules pretty early indeed).  New
conventions will also be needed for signature of .py, .pyc, .pyo, and
.so (or other binary DLLoid files containing Python extensions).

It appears to me that this is a project of orders of magnitude more work
than the original idea, which didn't assume the attacker could freely
alter sys.path, and protected only against altered or replaced zipfiles
specifically -- presumably files that have been legitimately placed on
the path by authorized agents.

> 
> or
> 
> import mymodule
> verify_module(mymodule)

Too late:'import mymodule' runs code in mymodule, shutting the barn door
after mymodule has tramped all over your system is little use.

> 
> Another question is, where to place (require|verify)_signature() (that
> could also take a CA key (or list of) as optional argument to only allow
> modules signed by this CA). It must not be imported from an untrusted
> module.
> The whole signing thing probably make only sense, if python and it's 
> stdlib can be trusted (=signed).

The stdlib Python (.pyc) parts could be moved into a .jar  (signed) just
as easily as into a .zip (unsigned).  The EXE and DLL's involved may be
quite a problem, though, since for those you're in the hands of the
operating system -- what could Python itself possibly do to stop an
altered Python.Exe from running?!

> 
> Or am I missing other useful applications of signed archives?

Remote distribution of code.  My program's startup checks if an updated
version of foobar.jar purports to be available, and if so downloads it
and places it where the previous version used to be.  Admittedly, in
this case, checking once and for all right after the download might work
better than checking after each and every import.  (Not sure why but
this reminds me of the old 'end to end approach' issue;-).

Unfortunately, Python currently doesn't have a working 'sandbox'
mechanism where code might run in a resricted way if it hadn't passed
all needed checks.  This lack, among other things, may certainly lessen
the usefulness of checks performed at (or, rather, just before) import
time.


Alex