configparser v/s file variables

[Steven D'Aprano]

On Wed, 27 Jun 2018 16:09:09 -0700, Jim Lee wrote:

> On 06/27/18 15:19, Steven D'Aprano wrote:
>> On Wed, 27 Jun 2018 12:15:23 -0700, Jim Lee wrote:
>>
>>>     It seems a bit silly to me to worry about arbitrary code
>>>     execution in
>>> an interpreted language like Python whose default runtime execution
>>> method is to parse the source code directly.  An attacker would be far
>>> more likely to simply modify the source to achieve his ends rather
>>> than try to inject a payload externally.
>> Spoken like a single user on a single-user machine who has
>> administrator privileges and can write to anything anywhere.
>>
>>
>>
> ...which is exactly the case I was trying to illustrate.  Another is the
> elevation of privileges (in a multi-user environment)  due to any of a
> number of methods.  The point is that the source code exists in the
> execution environment, and once one gains access to that code, one
> doesn't *need* anything else.

o_O

Yes, attacks by trusted insiders are the hardest to defend against. 
Betrayal of trust sucks. Trusted users with sufficient privileges could 
just modify the source code of your application or of Python itself. They 
could also attack your system in a thousand different ways.

But what about untrusted users with fewer privileges? They *can't* modify 
the source code of your application, or change the password on other 
accounts, or read arbitrary files, or masquerade as other users. Because 
they have unprivileged accounts.

So why give them the ability to escalate their privilege to that of your 
application (which probably can do lots of things they can't do) by 
directly executing Python code they supply?

Your argument is akin to:

"I gave my partner a key to my house, and they could rob me blind if they 
want. Since I trust them not to, there's no point in locking the door to 
the house when I go out, since they have a key."




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson