[netbsdusers]

> How can you implement an object capability system on WASM?

It's been well known for decades that the germ of an object capability system already exists in Unix - the file descriptor (that's why the control message for transferring them over sockets is called SCM_RIGHTS).

Capsicum was developed to make that potentiality a reality. It didn't require too much work. Since most things are represented by file descriptors, that was just a matter of tightening what you can do with the existing FDs (no going from a directory FD to its parent unless you have the right to the parent, or some parent of that parent, by another FD), and introducing process and anonymous shared memory FDs so that a global namespace is no longer needed to deal with these resources.

So WASI has derived itself from an actually existing object capability architecture - Capsicum - one which happens to be a simple refinement of the Unix API that everyone knows and every modern OS has at least been very much inspired by.

https://www.cl.cam.ac.uk/research/security/capsicum/

[tlavoie]

Capsicum looks very cool, but looks like support never got finished in Linux. It's still in FreeBSD, though, other BSDs as well? From what I understand (admittedly little), capabilities in Linux are more about ways to apply granular use of permissions that would otherwise need root. Not around limiting the ambient authority within one process. Seccomp can drop permissions, but again for the whole process.

On a related note, I found Thomas Leonard's blog post (2023) on Lambda Capabilities to be a very interesting approach: https://roscidus.com/blog/blog/2023/04/26/lambda-capabilitie...

[mike_hearn]

Parts of it are in Linux. Namespaces and pidfd got in, at least. PowerBoxes are in every OS these days including Linux via Flatpak.

[tlavoie]

Oh, interesting thanks! That would be like what's described here? https://docs.flatpak.org/en/latest/sandbox-permissions.html

Looking at Leonard's post from my earlier comment, I was really appreciating the ability to do this sort of restriction _within_ a single application. I know that the code I am writing is not doing anything malicious, but I'm still at the mercy of whatever dependent libraries I'm calling. (Think file parsers, for examples of code that often goes sideways.) His Eio effects library for OCaml supports Capsicum, which I could see as being awesome for any sort of multi-user server process in particular. https://github.com/ocaml-multicore/eio?tab=readme-ov-file#de...

[mike_hearn]

FDs are owned by processes, not libraries, and are by themselves not sufficient to implement a sandbox. A lot of policies people want to implement in the real world can't be expressed in UNIX or with file descriptors. For instance: UNIX kernels don't understand HTTP, but restricting socket access to particular domains is a common need. Of course, all of this can be hacked on top. Another example: stopping libraries quitting the process can't be done with fds.

Every modern OS has very much not been inspired by UNIX. Windows has little in common with it e.g. no fork/exec equivalents, the web is a sort of OS these days and has no shared heritage with UNIX, and many operating systems that ship a UNIX core as a convenience don't use its APIs or design patterns at the API level you're meant to use, e.g. an Android app doesn't look anything like a UNIX app, Cocoa APIs aren't UNIX either.

[netbsdusers]

Windows has extreme similarities with Unix, and if you would look at a really different OS like, for instance, IBM i, it becomes clear. The Windows-Unix affinity is so great that you even interact with devices through file handles by Read, Write, and IoCtl methods.

Check "Inside Windows NT" by Helen Custer, an official account. She explicitly credits the handles to Unix. That's not surprising - not only was Unix fresh on the minds of the NT developers, with quite a few of them having Unix backgrounds, but every conceptual ancestor of Windows NT was at least significantly influenced by Unix:

- VMS: The VAX/VMS team were in regular contact with Ken Thompson, and got the idea for channel IDs (= file descriptors) for representing open files and devices from him, as well as the idea of three standard channels which child processes inherit by default: input, output, error (the error one was at the time a very recent development, I think in Unix v6 or v7)

- MICA: Would have been a combined Unix and VMS compatible system.

- OS/2: FDs with read, write, ioctl again.

Even MS-DOS is already highly Unix-influenced: they brought in file descriptors in DOS 2.0 and even called the source files implementing the API "XENIX.ASM" and "XENIX2.ASM" (see the recent open source release.)

I have deliberately chosen to not make anything of the fact that Windows NT was intended to be POSIX compatible either (and even supports fork, which WASI mercifully doesn't) because my point is the fact that all modern general-purpose operating systems are at least very much inspired and deeply indebted to Unix. I would accept that OSes that are not general purpose may not be, and old operating systems made in siloed environments like IBM are fundamentally very different. IBM i is very different to Unix and that's clear in its native APIs even though

Cocoa and Android APIs don't look much like the basic Unix APIs, it's true, even if they are implemented in terms of them. WASI wants to define APIs at that lower level of abstraction. It's tackling the problem at a different level (the inter-process level) to what object capability _languages_ are tackling (the intra-process level).

[mike_hearn]

Right, if you compare against IBM i then everything looks the same :)

NT might have been intended to have a POSIX personality in the very beginnings of the project, but that never happened. People who have tried to make this work over the years have always retreated licking their wounds, including Microsoft themselves. WSL1 tried to use this and failed because NT is too different to UNIX to implement a Linux personality on top, so WSL2 is just a regular VM.