would be nice: import from archive
pink at odahoda.de
Sat Aug 28 13:53:20 CEST 2004
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
> 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.
> 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
>>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
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.
More information about the Python-list