10 ms·
> Instead of securing the "chain", we should instead isolate every library we import and run it under a sandbox. Didn't we have something like that in Java mor
by cesarb 11mo ago
> Instead of securing the "chain", we should instead isolate every library we import and run it under a sandbox.
Didn't we have something like that in Java more than a decade ago? IIRC, you could, for instance, restrict which classes could do things like opening a file or talking to the network.
It didn't quite work, and was abandoned. Turns out it's hard to sandbox a library; the exposed surface ended up being too large, and there were plenty of sandbox escapes.
> There are lots of native sandboxing in linux kernel. Bubblewrap, landlock, gvisor and kata (containers, not native), microVMs, namespaces (user, network), etc
What all of these have in common, is that they isolate processes, not libraries. If you could isolate each library in a separate process, without killing performance with IPC costs, you could use them; one example is desktop thumbnailers, which parse untrusted data, and can use sandboxes to protect against bugs in the image and video codec libraries they use.
- lmm 11mo ago> Didn't we have something like that in Java more than a decade ago? IIRC, you could, for instance, restrict which classes could do things like opening a file or talking to the network. > It didn't quite work, and was abandoned. Turns out it's hard to sandbox a library; the exposed surface ended up being too large, and there were plenty of sandbox escapes. The number of escapes is exaggerated. The issue was that it didn't have capabilities or anything like that, so it wasn't really used - you couldn't say "library X should be able to access files that the application has passed into it but not other files", you had to say "class X.Y.Z should be able to access the file /foo/bar/baz.jpeg" in your security policy. So it was unusably brittle and everyone just said "all code can access all files"