Hacker News Reader

Comment by syrusakbary | Hacker News Reader

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

Run it locally and see that filesystem access and network are completely sandboxed by default! :)

  wasmer run python/python

View on HN

What’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.

I’ve personally never been hit by a Trojaned Python project, why use any container or jail at all?

It is just a matter of time: https://pytorch.org/blog/compromised-nightly-dependency/

Is 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.

Shouldn'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

Desktop 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.

The 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.

Sandboxing 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.

Hugged to death?

    500: INTERNAL_SERVER_ERROR
    Code: FUNCTION_INVOCATION_FAILED
    ID: arn1::tpcjw-1696548167206-a333e98b1ba8

That's just a matter of perspective. My laptop is already perfectly isolated from your laptop, thank you very much.

> recently compiled Python 3.12.0 to WebAssembly

Any chain is as strong as its weakest link.

But not all composition is a chain.

A sandboxed solution is at least as strong as the sandbox.

Reply on news.ycombinator.com