On Sat, Oct 17, 2020 at 5:12 AM Lassi Kortela <[email protected]> wrote:
I believe sandboxing POSIX is only viable with support from the kernel > so we should wait for that. 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. Without kernel support, things look bleak for sandboxing of any kind. > The JVM has had more holes than swiss cheese, for example. 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. The same is true for a compiler that never generates a system call (few do) and whose runtime support does not include either general FFI or calls to open(). And so on through the whole thing. 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. > 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(). There aren't, and that's that. John Cowan http://vrici.lojban.org/~cowan [email protected] What is the sound of Perl? Is it not the sound of a [Ww]all that people have stopped banging their head against? --Larry
