51–60 of 323 posts
"pip" has a usability problem. It should do a lot more at preventing this kind of thing. When using pip, it's not easy to tell information like the release date, how many versions have been released, and so on. Since such info is available from PyPI API, I wrote my own "pypisearch" script to sort by latest release date and include number of releases to weed out packages that seem useful but are old or rarely released…
Is the code public? I'd love to use something like that.
Libraries should take lessons from writing safety critical code. If you identify libraries visually by name, the main problems are:
* easily misread characters like 1 (one) and l (lower case L), 0 and O, 2 and Z, 5 and S, or n and h.
* identifier names that differ only by on or few characters, especially if they are long.
It's possible to enforce a set rules that make identifier names are visually distinguishable and string distance measure to check all new libraries that are added against old names.
From the article... The libraries were "jeIlyfish" (with an upper case I) and "python3-dateutil" (not "dateutil"). Both libraries were close spellings of the real libraries. The lesson for developers is double check your imports! Spelling does count and there are lots of similarly named libraries (most are not malicious thankfully)
> "jeIlyfish" (with an upper case I) and "python3-dateutil" (not "dateutil"). Libraries should take lessons from writing safety critical code. If you identify libraries visually by name, the main problems are: * easily misread characters like 1 (one) and l (lower case L), 0 and O, 2 and Z, 5 and S, or n and h. * identifier names that differ only by on or few characters, especially if they are long. It's possible to e…
I don't know what the solution is but it feels like this is a much bigger issue and we need some rethinking of how OSes work by default. Apple has taken some steps it seems the last 2 MacOS updates where they block access to certain folders for lots of executables until the user specifically gives that permission. Unfortunately for things like python the permission is granted to the Terminal app so once given, all pr…
This is literally what SELinux does, and has been able to do for years. We don't need "default block lists" - we need solid SELinux policy in all distros.
I don't know what the solution is but it feels like this is a much bigger issue and we need some rethinking of how OSes work by default. Apple has taken some steps it seems the last 2 MacOS updates where they block access to certain folders for lots of executables until the user specifically gives that permission. Unfortunately for things like python the permission is granted to the Terminal app so once given, all pr…
This is literally what SELinux does, and has been able to do for years. We don't need "default block lists" - we need solid SELinux policy in all distros.
When I pip install paramiko, I do, in fact, want it to have access to my SSH keys. When I pip install ansible, I want ansible to be able to shell out to OpenSSH to use my keys. If I write custom Python code that calls gpg, I want that custom code to be able to load libraries that I've pip installed without the gpg subprocess being blocked from loading my keys. If I have a backup client in Python, and I tell it to back up my entire home directory, I want it backing up my entire home directory including private keys.
If I wanted an OS where I couldn't install arbitrary code and have it get to all my files for my own good, I'd use iOS. (I do, in fact, use iOS on my phone because I sometimes want this. But when I'm writing Python code, I don't.)
SELinux has been able to solve the problem of "if a policy says X can't get to Y, prevent X from getting to Y" for years. Regular UNIX permissions have been doing the same for decades. (Yes, SELinux and regular UNIX permissions take a different approach / let you write the policy differently, but that's the problem they're fundamentally solving; given a clear description of who to deny access to, deny this access.) Neither SELinux nor UNIX permissions nor anything else has solved the problem of "Actually, in this circumstance I mean for X to get to Y, but in that circumstance I don't, and this is obvious to a human but there's no clear programmable distinction between the cases."
To be clear - I think there is potentially something of a hybrid approach between the status quo and what newer OSes do. For instance, imagine if each virtualenv were its own sandboxed environment (which could be "SELinux context" or could just be "UNIX user account") and so if you're writing code in one project, things you pip install have access to that code but not your whole user account. I'm just saying that SELinux hasn't magically solved this problem because all it provides is tools you could use to solve it, not a solution itself.
Earlier quoted context omitted.
This is literally what SELinux does, and has been able to do for years. We don't need "default block lists" - we need solid SELinux policy in all distros.
There's a fair amount of other solutions to this too. Things today: - Protective monitoring. If it's stealing your key, it's presumably sending it somewhere, so somebody alerting should be going off asking clients are calling something external. - Peer review. Maybe its about time we question whether we should actually be running so many random modules without actually vendoring and reading the code. - Subscribing to…
> "jeIlyfish" (with an upper case I) and "python3-dateutil" (not "dateutil"). Libraries should take lessons from writing safety critical code. If you identify libraries visually by name, the main problems are: * easily misread characters like 1 (one) and l (lower case L), 0 and O, 2 and Z, 5 and S, or n and h. * identifier names that differ only by on or few characters, especially if they are long. It's possible to e…
Feel free to check it out: https://trustd.dev
we work preventatively, so as you download packages, the tool will analyse it and tell you of any issues found.
We’re looking to collaborate with devs to work out what features should be next.
I get the python3-dateutil because you might think it's an updated version of the standard library. But how does jellyfish with a different char for L work? Someone would need to copy and paste it. But if they go to pypi, it won't have many installs. Unless they started writing tutorials with: "okay now just pip install X"
If people are using number of installs as a safety metric, can't blackhats game that by having a bot install the package many times?