undefined

points

[-]

There is no security barrier at all in UNIX(-like) Os's between a caller/callee, this is not thing that python can just fix.

There are ways to harden and/or reduce privileges, but shells/scripting languages will always have this issue on any modern OS.

The UNIX way to help prevent that is really to run processes as another user, but people seem to refuse to do so. You should always expect any process running as your UID to be able to access any data owned or visible to your UID.

While it is possible to reduce the risk of disclosure, they are all wack-a-mole preventions protecting the low hanging fruit, not absolute guarantees.

That is purely due to how UNIX works [0]

[0] https://man7.org/linux/man-pages/man7/credentials.7.html

by surajrmal3 hours ago|

prev|

[-]

There is little that they can do short of running the programs in a VM. Linux distros aren't engineered to consider applications as something different from the user running them. You need a completely different security model to achieve that and the Python runtime isn't tackle that.

by sunshine-o1 hours ago|

parent|

[-]

In its inception 35 years ago the creator of python could not foresee how far python would go and how the environment would look like today. But nowadays there are a lot of security mechanisms they could leverage to adapt (from chroot by default to namespaces, cgroup, etc. on Linux, pledge, unveil on OpenBSD).

The very idea that you offer a (python) package installer that is gonna pull a tree of code published and updated by random people in an unvetted manner open the door to all the supply chain attacks we are seeing.

Around the same time (early 90s) Java was designed with high isolation in mind but the goal and vision was very different. And Java had its own problems.

I'm saying that because at some point the security problem is gonna really hurt the python ecosystem.