would be nice: import from archive

[Benjamin Niemann]

Alex Martelli wrote:

> 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
Mmmm, seems I missed this point...

> , 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.
correct

>>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?!
A use-case that came to my mind was a suid program that wants to verify 
that everything that it imports is what it expects, specifically not to 
allow the non-root user to inject any malicious replacement modules. 
Doing this with module signatures is probably not the easiest way...

>>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;-).
Yes, this could be handled by a generic 'file-signature-verification' 
mechanism. No need to delay verification until import.

> 
> 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.
Yep. Python treats us as adults. But adults often have to deal with 
children and the environment should give adults some kind of authority 
and places where the kiddies can play without causing damage... ;) This 
is currently not the case for Python.


> 
> 
> Alex