4 ms·
> It's also terrible for security. The security angle is interesting. The thing about independent processes is that we're relying on the OS to provide a wall
by joshmarlow 10y ago
> It's also terrible for security.
The security angle is interesting.
The thing about independent processes is that we're relying on the OS to provide a wall around each process to limit it's impact by default. Maybe a better approach would to be include something like chroot/containerization for execution of closures within the language? Ie, if program 'A' receives data from program 'B', it can evaluate that data in a sandbox with limited permissions (IO limitations like no networking, or CPU resource limitations and time limits) and receive exceptions if the closure tries to exceed it's permissions. That could fit in pretty cleanly with Common Lisp's condition system.
A con of this though: you could argue that it really breaks encapsulation; it's bad enough when different parts of a large program become too closely coupled - allowing different applications to depend on the internal state of each other could be a nightmare.
- catnaroek 10y agoNo runtime analysis can simultaneously allow all intended sharing and prevent all unintended sharing. Best you can hope for is a static analysis that rejects programs that would share objects in unintended ways.
- joshmarlow 10y agoI'm not talking about automated runtime analysis per se. The type of permission setting I had in mind would be specified by the programmer and enforced by the runtime/OS.
- catnaroek 10y agoAh, okay, makes sense.
- nickpsecurity 10y agoRelevant links here: https://news.ycombinator.com/item?id=12362583 https://news.ycombinator.com/item?id=12362583
- joshmarlow 10y agoI've really enjoyed your link-sharing lately. Thanks for spreading knowledge :)