Re: CloudABI and its successor, WebAssembly WASI Lassi Kortela 17 Oct 2020 16:16 UTC
> 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.