cap-std VS bubblewrap

I believe you mean capability based, like cap-std.

There might be another reason to prefer async-std right now: the Bytecode Alliance is working on a version of std with support for capability-based security (called cap-std: https://github.com/bytecodealliance/cap-std ), and their async version is based on async-std (called cap-async-std: https://github.com/bytecodealliance/cap-std/tree/main/cap-async-std ). Given the clout that the Bytecode Alliance has, async-std might end up carving a niche out in the Wasm domain.

Would love to see something like this implemented around creating a Process in cap-std ( https://github.com/bytecodealliance/cap-std/issues/190 )

I think it's not discussed enough how things like language features shape how library APIs are formed. People usually seem to only consider the question "how would I use this feature?" and not "how would the standard library look like with this feature?", which is surprising given how much builtin libraries affect the pleasantness of a language.

One of the things I'm excited to see is the cap-std project for Rust [0] given what Pony [1] has demonstrated is possible with capabilities. I'm also hoping that languages like Koka [2] and OCaml [3] will demonstrate interesting use cases for algebraic effects.

[0] https://github.com/bytecodealliance/cap-std

[1] https://www.ponylang.io/discover

[2] https://koka-lang.github.io

[3] https://github.com/ocaml-multicore/effects-examples

I'm not sure you could hack the control flow when running bytecode on the JVM, but I strongly doubt that. (The JVM is "high-level" as pointed out previously and doesn't execute ASM like code. So there is no of the attack surface you have to care on the ASM level).

And capabilities are anyway something that belongs into the OS — and than programs need to be written accordingly. The whole point of the capability-security model is that you can't add it after the fact. That's why UNIX isn't, and never will be, a capability secure OS.

But "sanboxing" some process running on a VM is completely independent of that!

WASM won't get you anything beyond a "simple sanbox" ootb. Exactly the same as you have in the other major VM runtimes.

If you want capability-secure Rust, there is much more to that. You have to change a lot of code, and use an alternative std. lib¹. Of course you can't than use any code (or OS functionality) when it isn't also capability-secure. Otherwise the model breaks.

To be capability-secure you have actually to rewrite the world…

¹ https://github.com/bytecodealliance/cap-std

The type system could definitely help. There's all sorts of things we can do. One really cool project is https://github.com/bytecodealliance/cap-std

On the topic of unsafe being used to describe raw file descriptors, on one hand, there is a sense in which file descriptors are pointers, into another memory. They can leak, dangle, alias, or be forged, in exactly the same way. On the other, there is an open issue about this.

Nothing nix specific but you may be interested in https://github.com/containers/bubblewrap

Recently, I came across Chainguard and wrote the article How to build Docker Images with Melange and Apko. As a fervent supporter of Kubernetes and GitLab CI, I was eager to experiment with building images using Melange in this particular setup. GitLab's shared Runners work seamlessly with Bubblewrap, eliminating the need for additional configurations. This post is intended for enthusiasts like myself, interested in hosting their own Kubernetes Runners and leveraging the Kubernetes Runner Type of Melange.

```

This is basically manually invoking what Flatpak does:

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.

While trying to find out more comparison information, found this light on details issue:

https://github.com/containers/bubblewrap/issues/81

It mentions nsjail and minijail.