Email list hosting service & mailing list manager

CloudABI John Cowan (14 Oct 2020 17:32 UTC)
Re: CloudABI Arthur A. Gleckler (14 Oct 2020 18:29 UTC)
CloudABI and its successor, WebAssembly WASI Lassi Kortela (15 Oct 2020 19:00 UTC)
Re: CloudABI and its successor, WebAssembly WASI John Cowan (16 Oct 2020 14:25 UTC)
Re: CloudABI and its successor, WebAssembly WASI Lassi Kortela (17 Oct 2020 09:12 UTC)
Re: CloudABI and its successor, WebAssembly WASI John Cowan (17 Oct 2020 15:54 UTC)
Re: CloudABI and its successor, WebAssembly WASI Lassi Kortela (17 Oct 2020 16:17 UTC)
Re: CloudABI and its successor, WebAssembly WASI John Cowan (17 Oct 2020 22:36 UTC)
Re: CloudABI and its successor, WebAssembly WASI Lassi Kortela (17 Oct 2020 23:26 UTC)

Re: CloudABI and its successor, WebAssembly WASI Lassi Kortela 17 Oct 2020 09:12 UTC

>> John, do you have a particular Scheme interface in mind?

> If we converted the function calls to procedures, the
> structs to record types, and the constants to constants, we'd have a
> capability-security Scheme API for Posix systems.  Then we could strip
> down cloudlibc to remove the things that aren't relevant to CloudABI,
> and then interface it to a Scheme using the Scheme's FFI.

I believe sandboxing POSIX is only viable with support from the kernel
so we should wait for that. OpenBSD's pledge() could probably be
leveraged today to implement most of CloudABI with strict enforcement
from the kernel. That would be an interesting project if anyone has the
spare cycles to do it. Mini-Scheme and TinyScheme are easy to hack for
purposes like this.

Without kernel support, things look bleak for sandboxing of any kind.
The JVM has had more holes than swiss cheese, for example. The kernel is
the ultimate arbiter of virtual addressing and file system traversal so
it has a real shot at enforcing boundaries; mimicking all that stuff in
a virtual machine is very dodgy.