Vinay Sajip <vinay_sa...@yahoo.co.uk> added the comment:

Having reflected on this further, ISTM that limiting the scope of evaluation is 
not the correct answer. For example, a malicious user could still send a bogus 
configuration which, for example, just turns the verbosity of all loggers off, 
or configures a huge number of bogus loggers. This would certainly be allowed 
even by a limited-evaluation scheme if a user legitimately wanted to do so; but 
if a malicious user sends the exact same “legal” configuration, it is still a 
security exploit because the consequences may be undesirable to the victim.

But how is the listener to know whether or not the configuration is coming from 
a legitimate source (a client process controlled by the same user who is 
running the process which uses listen())  or a malicious user (a client process 
controlled by some other user)? The simplest answer would appear to be a shared 
secret: When listen() is called, it is passed a text passphrase, which is also 
known to legitimate clients. When handling a configuration request via the 
socket, the configuration is checked to see if it contains the passphrase. If 
it does, the request is processed; otherwise, it is ignored.

In the fileConfig() input data, the passphrase could be provided via a 
passphrase=secret entry in the [default] section. In the dictConfig() input 
data, the passphrase could be provided against the passphrase key in the dict 
which is passed to dictConfig(). The checking would be done in the request 
handler code before calling fileConfig() or dictConfig(). If the passphrase 
argument to the listen() call is None (the default, preserving the current 
behaviour) no passphrase checking would be done.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15452>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to