> The idea is to whitelist by disabling certain libraries.  Without
> (scheme file), (scheme load), (scheme process-context), and SRFI 170,
> there is no access from Scheme to anything outside it.  There are still
> ports, but only string ports; the current-*-port parameters are bound to
> #f.  Then we add (cloudabi) and we are in the CloudABI environment
> without worrying about what the kernel does and does not allow.

This is unwise on multiple levels.

1. Interpreters are written in C. You trust C code more than most
security experts and many programmers do. Scheme interpreters don't have
exploits because they are not as popular as the JVM so it doesn't pay to
write exploits. Not because they are bug-free.

2. We desire to implement one access control feature: restricting access
to file system pathnames. In a monolithic kernel OS, those checks belong
in the kernel. If we have checks in the kernel, the checks in Scheme are
redundant.

3. If we don't have checks in the kernel, they should be put in the
kernel, where they have full authority, knowledge and efficiency to do
what they need to do, and will benefit all userland programming
languages. This is much better than putting harder-to-write, less
efficient checks in one interpreter of one programming language in
userland. (Maybe you want to do the checks by restricting library
imports or compiling the interpreter with a limited feature set; in this
case, see point 1.)

> That's because it was trying to allow local programs to have full access
> to the kernel and downloaded programs to have only limited access, all
> within the same JVM.  An interpreter that doesn't implement FFI and
> doesn't provide the R7RS-small open-*-*-file procedures simply cannot
> read or write to the filesystem except on already-known ports.

That is only true as long as Scheme is unpopular enough that people are
not paid to find exploits.

> Not really.   If you want to know if a `sed` program can open a socket,
> it suffices to audit the sources of GNU and BSD sed to see if there are
> any calls on socket().

I'm pretty sure there are approximately zero security researchers who
would agree with that.