It is absurd for any user to use a half baked Python interpreter, also one that will always majorly lag behind CPython in its support. I advise sandboxing CPython instead using OS features.
It is absurd for any user to use a half baked Python interpreter, also one that will always majorly lag behind CPython in its support. I advise sandboxing CPython instead using OS features.
Python already has a lot of half-baked (all the way up to nearly-fully-baked) interpreters, what's one more?
https://en.wikipedia.org/wiki/List_of_Python_software#Python...
How do I sandbox CPython using OS features?
(Genuine question, I've been trying to find reliable, well documented, robust patterns for doing this for years! I need it across macOS and Linux and ideally Windows too. Preferably without having to run anything as root.)
It could be difficult. My first thought would be a SELinux policy like this article attempted:
https://danwalsh.livejournal.com/28545.html
One might have different profiles with different permissions. A network service usually wouldn't need your hone directory while a personal utility might not need networking.
Also, that concept could be mixed with subprocess-style sandboxing. The two processes, main and sandboxed, might have different policies. The sandboxed one can only talk to main process over a specific channel. Nothing else. People usually also meter their CPU, RAM, etc.
INTEGRITY RTOS had language-specific runtimes, esp Ada and Java, that ran directly on the microkernel. A POSIX app or Linux VM could run side by side with it. Then, some middleware for inter-process communication let them talk to each other.
Docker and other container runners allow it. https://containers.dev/ allows it too.
https://github.com/microsoft/litebox might somehow allow it too if a tool can be built on top of it, but there is no documentation.
Every time I use Docker as a sandbox people warn me to watch out for "container escapes".
I trust Firecracker more because it was built by AWS specifically to sandbox Lambdas, but it doesn't work on macOS and is pretty fiddly to run on Linux.
Outside of VM usage, the answer seems to be (on top of containerization and selinux) writing a tight seccomp filter.
Gleaned from https://github.com/containers/bubblewrap/blob/0c408e156b12dd... and https://github.com/containers/bubblewrap/tree/0c408e156b12dd...
I think ChatGPT can do a much better job than I can for guiding how to safely use Docker as a sandbox: /share/69875282-1e38-8012-b627-7c0a678f9365
It's not industrial-grade safety for public use, but it'll do for personal use. Other tools for it are also mentioned.
The repo does make a case for this, namely speed, which does make sense.
True, but while CPython does have a reputation for slow startup, completely re-implementing isn't the only way to work around it - e.g. with eryx [1] I've managed to pre-initialize and snapshots the Wasm and pre-compile it, to get real CPython starting in ~15ms, without compromising on language features. It's doable!
[1] https://github.com/eryx-org/eryx
Speed is not a feature if there isn't even syntax parity with CPython.
Not having parity is a property they want, similar to Starlark. They explicitly want a less capable language for sandboxing.
Think of it as a language for their use case with Python's syntax and not a Python implementation. I don't know if it's a good idea or not, I'm just an intrigued onlooker, but I think lifting a familiar syntax is a legitimate strategy for writing DSLs.
Not having syntax parity with Python == not Python. End of story. The title stays "Python interpreter" which accordingly it is not.