4 ms·

Is Python a safe language? It doesn’t seem to have the sorts of problems other languages do. Why is that?

franga2000 5y ago
Most interpreted languages are "safer" in this regard as they don't leave the memory management up to their users. The interpreter itself could still have such bugs, but that's a comparably much smaller attack surface and has far more eyes on it that any random person's code, so these are less frequent. And it's not just fully interpreted languages - any language that manages memory for your and doesn't let you mess with it yourself (like Java, C#...) will be safer, assuming the compiler and runtime are secure.
aix1 5y ago
There are at least two things that could be contributing to this perception: 1. Python is (usually) an interpreted language, and it's probably true to say that interpreted languages tend to have a lower attack surface (at the cost of lowered performance). 2. While Python is very popular in certain domains (numerical computing, ML etc), there are few low-level systems that are written in Python.
7373737373 5y ago
Absolutely not, unfortunately. One of the architectural issues plaguing even comparatively memory-safe languages is the fact that there is a global scope that's accessible from anywhere. In some Python versions even numbers or truth values could be redefined. [0] This makes it impossible to sandbox functions or imported modules, because they can communicate arbitrarily. But communication/access security is not the only problem. Resource security is something I haven't seen any significant language (besides Java perhaps) try to approach - being able to limit the memory and cpu usage of a (part of a) program. Modern languages should make it possible to do both with just a few lines of code. I recommend reading about Capability Security[1], the E language[2] and the Principle of least Authority (POLA) [3] [0] https://hforsten.com/redefining-the-number-2-in-python.html https://hforsten.com/redefining-the-number-2-in-python.html [1] http://www.cap-lore.com/CapTheory/ http://www.cap-lore.com/CapTheory/ https://en.m.wikipedia.org/wiki/Capability-based_security https://en.m.wikipedia.org/wiki/Capability-based_security [2] http://www.erights.org/ http://www.erights.org/ [3] https://medium.com/agoric/pola-would-have-prevented-the-event-stream-incident-45653ecbda99 https://medium.com/agoric/pola-would-have-prevented-the-even... These originated in the mainframe era, in a connected world before the internet, at the inception of the first multi-user systems: https://github.com/void4/notes/issues/41 https://github.com/void4/notes/issues/41
- pyuser583 5y ago
  lol … this is the first time I’ve heard some one mention the E language outside the context of “inspiration for Scala.” This is a very interesting comment, and I’m going to study it and the links you gave. Thank you!
- abecedarius 5y ago
  CPython is not even memory-safe. The compiled bytecode is accessible to ordinary Python code able to replace it with 'incorrect' bytecode that causes out-of-bounds memory access by the C interpreter. (Presumably an unusual thing to do -- I've seen libraries doing bytecode hacks but I'm not sure how popular any of them are.)
  - pyuser583 5y ago
    The compiled byte code in the file system is accessible and reversible, yes. But not once the interpreter has imported it. A subsequent import could patch the Python object namespace, but that’s normal and intended. If a program has access to the byte code files, it presumable has access to the actual .py files, and can easily change them to do whatever mayhem it wants.
    - abecedarius 5y ago
      You totally can create bytecode and jump into it from Python, no .py files needed. See https://codewords.recurse.com/issues/seven/dragon-taming-with-tailbiter-a-bytecode-compiler https://codewords.recurse.com/issues/seven/dragon-taming-wit... where types.CodeType gets invoked.
- pyuser583 5y ago
  I find the idea of resource security very interesting - I haven’t heard of it before. Isn’t that the opposite of secure? Pulling resource allocations out of the kernel and putting it into user land?
  - 7373737373 5y ago

franga2000 5y ago

Most interpreted languages are "safer" in this regard as they don't leave the memory management up to their users. The interpreter itself could still have such bugs, but that's a comparably much smaller attack surface and has far more eyes on it that any random person's code, so these are less frequent. And it's not just fully interpreted languages - any language that manages memory for your and doesn't let you mess with it yourself (like Java, C#...) will be safer, assuming the compiler and runtime are secure.

aix1 5y ago

There are at least two things that could be contributing to this perception: 1. Python is (usually) an interpreted language, and it's probably true to say that interpreted languages tend to have a lower attack surface (at the cost of lowered performance). 2. While Python is very popular in certain domains (numerical computing, ML etc), there are few low-level systems that are written in Python.

7373737373 5y ago

Absolutely not, unfortunately. One of the architectural issues plaguing even comparatively memory-safe languages is the fact that there is a global scope that's accessible from anywhere. In some Python versions even numbers or truth values could be redefined. [0] This makes it impossible to sandbox functions or imported modules, because they can communicate arbitrarily. But communication/access security is not the only problem. Resource security is something I haven't seen any significant language (besides Java perhaps) try to approach - being able to limit the memory and cpu usage of a (part of a) program. Modern languages should make it possible to do both with just a few lines of code. I recommend reading about Capability Security[1], the E language[2] and the Principle of least Authority (POLA) [3] [0] https://hforsten.com/redefining-the-number-2-in-python.html https://hforsten.com/redefining-the-number-2-in-python.html [1] http://www.cap-lore.com/CapTheory/ http://www.cap-lore.com/CapTheory/ https://en.m.wikipedia.org/wiki/Capability-based_security https://en.m.wikipedia.org/wiki/Capability-based_security [2] http://www.erights.org/ http://www.erights.org/ [3] https://medium.com/agoric/pola-would-have-prevented-the-event-stream-incident-45653ecbda99 https://medium.com/agoric/pola-would-have-prevented-the-even... These originated in the mainframe era, in a connected world before the internet, at the inception of the first multi-user systems: https://github.com/void4/notes/issues/41 https://github.com/void4/notes/issues/41

pyuser583 5y ago
lol … this is the first time I’ve heard some one mention the E language outside the context of “inspiration for Scala.” This is a very interesting comment, and I’m going to study it and the links you gave. Thank you!
abecedarius 5y ago
CPython is not even memory-safe. The compiled bytecode is accessible to ordinary Python code able to replace it with 'incorrect' bytecode that causes out-of-bounds memory access by the C interpreter. (Presumably an unusual thing to do -- I've seen libraries doing bytecode hacks but I'm not sure how popular any of them are.)
- pyuser583 5y ago
  The compiled byte code in the file system is accessible and reversible, yes. But not once the interpreter has imported it. A subsequent import could patch the Python object namespace, but that’s normal and intended. If a program has access to the byte code files, it presumable has access to the actual .py files, and can easily change them to do whatever mayhem it wants.
  - abecedarius 5y ago
    You totally can create bytecode and jump into it from Python, no .py files needed. See https://codewords.recurse.com/issues/seven/dragon-taming-with-tailbiter-a-bytecode-compiler https://codewords.recurse.com/issues/seven/dragon-taming-wit... where types.CodeType gets invoked.
pyuser583 5y ago
I find the idea of resource security very interesting - I haven’t heard of it before. Isn’t that the opposite of secure? Pulling resource allocations out of the kernel and putting it into user land?
- 7373737373 5y ago