5 ms·
This is great. On a related note, we recently compiled Python 3.12.0 to WebAssembly: using it should shield almost any use case of malicious behavior even on ex
by syrusakbary 3y ago
This is great. On a related note, we recently compiled Python 3.12.0 to WebAssembly: using it should shield almost any use case of malicious behavior even on external untrusted modules.
https://wasmer.io/python/python https://wasmer.io/python/python
Run it locally and see that filesystem access and network are completely sandboxed by default! :)
wasmer run python/python
- adolph 3y ago> recently compiled Python 3.12.0 to WebAssembly Any chain is as strong as its weakest link.
- gizmo686 3y agoBut not all composition is a chain. A sandboxed solution is at least as strong as the sandbox.
- miohtama 3y agoWhat’s benefit of this over running Python in a container like Docker? I know Docker is not 100% watertight, but it’s very unlikely a normal user encounters trojaned Python code that tries to break out from a container. The run-time penalty for using WebAssembly for Python is pretty severe at the moment, at least what I have tried.
- deleted 3y ago[deleted]
- chalsprhebaodu 3y agoI’ve personally never been hit by a Trojaned Python project, why use any container or jail at all?
- kjok 3y agoIt is just a matter of time: https://pytorch.org/blog/compromised-nightly-dependency/ https://pytorch.org/blog/compromised-nightly-dependency/
- hifromwork 3y agoIs this sarcasm? Hard to tell on the internet sometimes. Anyway: * It's scary enough to be hit one time. It's no fun to have one's all passwords, accounts and keys stolen, and sometimes have files encrypted with a ransom demand on top of that. * Ideally we'd like to have a secure-by-default world, where the mere act of installing a dependency or running a helper script doesn't compromise your whole system. We're almost there with our phones, we just need to rethink our desktops too. Of course I don't say you should use containers/sandboxes. It's a tradeoff everyone has to make, but there are many reasons some people (me included) prefer to sandbox everything as much as reasonably possible.
- onesphere 3y agoShouldn't the OS already do containering with its processes (based on user)? That's kind of the [functional context] approach I take with: https://github.com/matrixApi/encapsule https://github.com/matrixApi/encapsule
- miohtama 3y agoDesktop and server operating system do not prevent any process to access file system. Any process can effectively steal any work you have on your file system, and also perform malware attacks by encrypting your files. This is not true for mobile operating systems like Android and iOS where processes cannot know about other processes or access file system.
- insanitybit 3y agoThe typical User in linux is pretty unconstrained. They can view a lot of global resources, perform arbitrary system calls, view other processes, other users, etc. It's not really a tight sandbox. That's why Linux offers other, more powerful mechanisms for sandboxing such as namespaces, which are the backbone of containers.
- kjok 3y agoSandboxing is always good. However, the problem is figuring out accurate per-module policies (what to allow/disallow) For example, a default block-all network policy would also block legitimate functionality.
- hoosieree 3y agoThat's just a matter of perspective. My laptop is already perfectly isolated from your laptop, thank you very much.
- hifromwork 3y agoHugged to death? 500: INTERNAL_SERVER_ERROR Code: FUNCTION_INVOCATION_FAILED ID: arn1::tpcjw-1696548167206-a333e98b1ba8