Re: configparser v/s file variables
On 06/28/18 16:44, Steven D'Aprano wrote: I agree with you that it's a bad idea. Aside from the little fact that you described concerns about using Python code for settings as "silly". Umm, no. I said that worrying about arbitrary code execution in an interpreted language seemed silly. Please be more accurate in your paraphrases. Data validation is a red herring: it is no more or less necessary to validate user settings regardless of their source. Whether they come from reading an INI file or from importing a Python file, you still need to check that they have valid values. You are making a strawman argument, since you are (again) misrepresenting what I said. Therefore, I will give you no more opportunities. -Jim -- https://mail.python.org/mailman/listinfo/python-list
Re: configparser v/s file variables
On Thu, 28 Jun 2018 10:58:36 -0700, Jim Lee wrote:
> On 06/28/18 07:30, Grant Edwards wrote:
>> I still maintain it's a bad idea to run arbitrary code found in
>> user-edited config files.
>>
>> There may be cases where somebody has figured out how to muck with a
>> config file that's shared among multiple users, or has tricked somebody
>> into including something from an untrusted source in an include file.
>>
>> Or there could be users who don't know what they're doing and
>> unwittingly type something harmful into a config file:
>>
>>bad_command = os.system("rm -rf ~/*")
>>
>> Yes, I know, users would never be that dumb...
>>
> I agree with you that it's a bad idea.
Aside from the little fact that you described concerns about using Python
code for settings as "silly".
> I was pointing out that I look
> at it from an input validation viewpoint rather than a security
> viewpoint - that's all.
You have made it abundantly clear that you aren't thinking about security.
> Absolute security isn't a solvable problem. It isn't even a technical
> problem. But that's a discussion for another time...
Nobody is talking about "absolute security".
We're talking about *one* aspect of security: given the need to collect
user-supplied settings, is it acceptable to get the settings from
executable Python code?
Data validation is a red herring: it is no more or less necessary to
validate user settings regardless of their source. Whether they come from
reading an INI file or from importing a Python file, you still need to
check that they have valid values.
--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson
--
https://mail.python.org/mailman/listinfo/python-list
Re: configparser v/s file variables
On 06/28/18 07:30, Grant Edwards wrote:
I still maintain it's a bad idea to run arbitrary code found in
user-edited config files.
There may be cases where somebody has figured out how to muck with a
config file that's shared among multiple users, or has tricked
somebody into including something from an untrusted source in an
include file.
Or there could be users who don't know what they're doing and
unwittingly type something harmful into a config file:
bad_command = os.system("rm -rf ~/*")
Yes, I know, users would never be that dumb...
I agree with you that it's a bad idea. I was pointing out that I look
at it from an input validation viewpoint rather than a security
viewpoint - that's all.
Absolute security isn't a solvable problem. It isn't even a technical
problem. But that's a discussion for another time...
-Jim
--
https://mail.python.org/mailman/listinfo/python-list
Re: configparser v/s file variables
On 06/28/18 00:46, Steven D'Aprano wrote: 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? ??? I don't follow. I never suggested allowing someone the ability to directly execute user-supplied Python code. However, if they have the privileges necessary to run the application, I don't see the security risk. Many applications have embedded scripting engines that do just that. 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." Not exactly. The original question was about reading config variables from a file in Python. That sort of thing didn't suggest (to me) a world-facing web app or other security-conscious situation. It's more like leaving the door unlocked while I'm home... -Jim -- https://mail.python.org/mailman/listinfo/python-list
Re: configparser v/s file variables
On 2018-06-28, Steven D'Aprano wrote:
> 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?
To be fair, that situation isn't common. The vast majority of
applications run with the exact same set of privledges as the user who
invoked them. At least that's the case on Linux/Unix. Perhaps Windows
apps are different and the usual case is for many applications to have
dangerous capabilities that an average user who's invoking them
shouldn't have. That sounds stupid enough to be something that would
be normal for Windows.
I still maintain it's a bad idea to run arbitrary code found in
user-edited config files.
There may be cases where somebody has figured out how to muck with a
config file that's shared among multiple users, or has tricked
somebody into including something from an untrusted source in an
include file.
Or there could be users who don't know what they're doing and
unwittingly type something harmful into a config file:
bad_command = os.system("rm -rf ~/*")
Yes, I know, users would never be that dumb...
--
Grant Edwards grant.b.edwardsYow! Everybody gets free
at BORSCHT!
gmail.com
--
https://mail.python.org/mailman/listinfo/python-list
Re: configparser v/s file variables
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: configparser v/s file variables
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. -Jim -Jim -- https://mail.python.org/mailman/listinfo/python-list
Re: configparser v/s file variables
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. -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: configparser v/s file variables
i think variables also in the case of PORT = 12345 Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ And it doesn't require that the end user have any knowlege of Python > syntax or sematics. > -- https://mail.python.org/mailman/listinfo/python-list
Re: configparser v/s file variables
On 2018-06-27, 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. Maybe it's not a deliberate attack. Good application design is also about preventing accidents. > An attacker would be far more likely to simply modify the source to > achieve his ends rather than try to inject a payload externally. That's true if the user has write permission for the program itself. That's not how applications are usually installed (at least not on the OSes I use). > These days, "execute arbitrary code" implies a deliberate attack. Perhaps I should have phrased it differently: I didn't mean to restrict my comments to a deliberate attack. > Now, if you used input validation as an argument, I would agree that > configparser is, if not safer, easier. And it doesn't require that the end user have any knowlege of Python syntax or sematics. -- Grant Edwards grant.b.edwardsYow! ... I want FORTY-TWO at TRYNEL FLOATATION SYSTEMS gmail.cominstalled within SIX AND A HALF HOURS!!! -- https://mail.python.org/mailman/listinfo/python-list
Re: configparser v/s file variables
On 06/27/2018 12:15 PM, Jim Lee wrote: On 06/27/18 11:45, Abdur-Rahmaan Janhangeer wrote: and that closes it, thanks !!! Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ Importing variables from a file is dangerous because it can execute arbitrary code. It should never be done with files provided by the user. Using configparser is far, far safer. 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. These days, "execute arbitrary code" implies a deliberate attack. Now, if you used input validation as an argument, I would agree that configparser is, if not safer, easier. -Jim Not at all. Because if you're assuming a malicious user (who wasn't the one to install it), then you're assuming a multi-user environment. In which case the malicious user wouldn't have modify access to the code, unless your program says "Hey, Mal E. Factor, why don't you run your arbitrary code in my environment?" -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix. -- https://mail.python.org/mailman/listinfo/python-list
Re: configparser v/s file variables
On 06/27/18 11:45, Abdur-Rahmaan Janhangeer wrote: and that closes it, thanks !!! Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ Importing variables from a file is dangerous because it can execute arbitrary code. It should never be done with files provided by the user. Using configparser is far, far safer. 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. These days, "execute arbitrary code" implies a deliberate attack. Now, if you used input validation as an argument, I would agree that configparser is, if not safer, easier. -Jim -- https://mail.python.org/mailman/listinfo/python-list
Re: configparser v/s file variables
and that closes it, thanks !!! Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ Importing variables from a file is dangerous because it can execute > arbitrary code. It should never be done with files provided by the > user. > > Using configparser is far, far safer. > -- https://mail.python.org/mailman/listinfo/python-list
Re: configparser v/s file variables
On 2018-06-27, Abdur-Rahmaan Janhangeer wrote: > what is more recommended and why? using configparser for settings or import > variables from file? Importing variables from a file is dangerous because it can execute arbitrary code. It should never be done with files provided by the user. Using configparser is far, far safer. -- Grant Edwards grant.b.edwardsYow! Psychoanalysis?? at I thought this was a nude gmail.comrap session!!! -- https://mail.python.org/mailman/listinfo/python-list
