Re:The Nature of Lisp (2006)
by agumonkey on Wednesday May 20, 2015 @10:30AM
(#9576539)
AFAIUI you write restricted evaluators to deal with external code. You can dismiss or rewrite any form you want, avoid IO, system calls and such. I never looked into it so maybe it's possible to escape that, it's been used on an irc bot for #clojure, so it's not stupid; but there's always a possibility for crazy ideas like crafting memory patterns and trying to DDoS the evaluator in order for these to become code (complete speculation based on Return Oriented Programming).
[ Parent
| on HN ]
Re:The Nature of Lisp (2006)
by brandmeyer on Wednesday May 20, 2015 @10:42AM
(#9576618)
Combining syntactic closures with the Scheme module system's ability to carefully control exports and imports seems like it should be enough.
However, high-security language runtimes have a history of being subverted anyway.
I don't know what to Google ('lisp evaluator security' wasn't fruitful) but I'd love to see research on the subject.
Jonathan Rees's 1995 paper "A Security Kernel Based on the Lambda Calculus" was enlightening. Not only was it capability-based security in Scheme -- but capabilities are lambdas!