5 ms·
It's (partially) a fundamental problem with Python and (all?) other popular programming languages. The majority of libraries don't need more authority than doin
by 7373737373 3y ago
It's (partially) a fundamental problem with Python and (all?) other popular programming languages. The majority of libraries don't need more authority than doing (some) computation, yet any Python script can access anything and everything by default.
The https://en.wikipedia.org/wiki/Principle_of_least_privilege https://en.wikipedia.org/wiki/Principle_of_least_privilege as constructed by https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security is the solution for this, yet Python will probably never be capable of this kind of internal encapsulation, it's too much of a fundamental change - and even if some sort of sandboxing ability is accomplished, creating separate/recursive sandboxes (needed when importing more, separate libraries which in turn import libraries whose authority they want to limit) will probably require another interpreter instance for each sandbox (as with WebAssembly).
I hope current and future language designers will take this into account, and construct their compilers, virtual machines and interpreters accordingly. Python was created before the internet as we know it now existed, so perhaps its lack of security mechanisms shouldn't be surprising. But it and any new developments that fail to consider this aspect of computation will be fundamentally flawed from the beginning.
https://github.com/void4/notes/issues/41 https://github.com/void4/notes/issues/41
- simonw 3y agoThis is why I'm so interested in running Python (and almost every other language) inside a WebAssembly sandbox. It's 2023. I never want to run untrusted code on any of my devices outside of a sandbox ever again. WebAssembly feels like it should be that sandbox. Every few months I check to see if it's easy enough to run regular Python/JavaScript/etc code inside a WebAssembly sandbox yet... we're not quite there but it feels really close. More notes here: https://til.simonwillison.net/webassembly/python-in-a-wasm-sandbox https://til.simonwillison.net/webassembly/python-in-a-wasm-s...
- mhh__ 3y agoWebAssembly as a platform is probably as good as any other, but I think as an ISA and compilation target they flubbed a lot of the basics. It's slightly too clever, slightly too awkward to target seamlessly etc
- ashishbijlani 3y agoCurious to know why existing sandboxing/isolation technologies like VMs & Containers not enough here?
- simonw 3y agoThey're not lightweight and easy enough to use. I have Docker on my Mac. I run things in it if I have to, but it's pretty resource heavy and I have to look at my notes every time I want to run "docker run". Plus Docker isn't actually a fully secure sandbox! There's Firecracker, which I believe is secure (AWS built it for Lambda after all) but good luck figuring out how to run that on a Mac. I want something that's tiny, fast, ridiculously easy to use and that I can run dozens if not hundreds of instances. WebAssembly is almost that thing.
- rrherr 3y agoAgreed about Docker. Personally, I use Google Colab for my convenient, lightweight Python sandbox. But I’d rather not depend on Google. It feels weird that this is my best option for now.
- Intralexical 3y ago> Personally, I use Google Colab for my convenient, lightweight Python sandbox. But I’d rather not depend on Google. It feels weird that this is my best option for now. `bwrap` is great for this on Linux. A one line alias should let you run any program in a lightweight and highly customizable sandbox safely-ish. See my reply to the parent comment for an example.
- Intralexical 3y ago> They're not lightweight and easy enough to use. ``` $ alias SafeRun="bwrap --ro-bind / / --dev /dev --proc /proc --unshare-all --tmpfs ~ --bind ~/Untrusted ~/Untrusted" $ SafeRun python3 ~/Untrusted/RandomScript.py $ SafeRun ~/Untrusted/RandomExecutable ``` This is basically manually invoking what Flatpak does: https://github.com/containers/bubblewrap https://github.com/containers/bubblewrap This is also useful for more than just security. E.G., you can test how your app would behave on a fresh install by masking your user configuration files. I personally also have a tool that uses it to basically bundle all dependencies from an entire Linux distribution in order to make highly portable AppImages— Been meaning to post that, will get around to it eventually maybe. The flags above should hide your user data (`--tmpfs`), disable network access (`--unshare-all`), hide/virtualize devices and OS state (`--dev` and `--proc`), and make the rest of the root filesystem read-only (`--ro-bind`— Including the insecure X11 socket in `/tmp`, which you might want to expose for GUI apps). Check them against `bwrap --help`; I might have omitted one or two more things you'd need.
- formerly_proven 3y agoJava and C# used to have this, but both removed it later on.
- 7373737373 3y agoI'd love to read more about why these attempts were abandoned, and how they got the idea to try
- formerly_proven 3y agoThe JEP to remove it chronicles the rise and fall of java.security: https://openjdk.org/jeps/411 https://openjdk.org/jeps/411