Generally, you just don't expose your Lisp evaluator to untrusted users. Lisp macros are a powerful language feature, and to allow your user to evaluate arbitrary code is exactly as dangerous as with any other system.

Emacs is not meant to be secure against user scripts. You could even say that's an integral part of its whole philosophy: the user can do whatever she likes, and her scripts too.

It does have some rudimentary safety. For example, color themes by default can't run Lisp code. They are written as Lisp data structures, but they aren't run through the evaluator unless the user explicitly allows it.

Just like every other language.

You either

- Expose the entire language and then there's not much you can do to prevent something harmful.

- Expose a subset of the language perhaps through parsing for harmful patterns or by somehow making potentially harmful functions unreachable.

- Expose a more restricted language (scripting like c/lua) that you control and know its full capabilities.

The only difference I can think of is that it's easier to write flexible and dynamically modifiable software in lisp than in most mainstream languages.

Capability based systems offer better options.

All access to anything important (network, files, other commands, etc) have to happen through opaque handles called capabilities. Think of them as objects that you can't look for.

When you call code, you pass it a set of capabilities that are available. That is all it can ever access.

But the whole language and environment needs to be defined from the bottom up to enable this.

The end result has been years of (practical) research going into an actually safe, actually sandboxed, actually secure cross-platform platform: https://developer.chrome.com/native-client

I raise my right eyebrow of incredulity at the "actually secure" claim, considering that even Chrome regularly falls in contests like Pwn2Own.

Well, native client isn't chrome itself. Chrome has to deal with dumb OS issues and platform interop. Native Client is more of a complete data/instruction sandbox: https://developer.chrome.com/native-client/faq#security-and-...

Plus, they are taking their time (years and years and years) to get it working properly before driving public adoption.

It's up to the programmer to decide what code/data is trusted and untrusted. So you wouldn't `eval` any S-expressions that could be submitted by a user. It's really no different in terms of security implications than any other dynamic language like Ruby, Python, Perl, PHP, Javascript...

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).

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!

http://mumble.net/~jar/pubs/secureos/

Ha, I knew it. Lambda the ultimate everything.

Don't use read or eval willy nilly. If you have to use read, at the very least turn off read-eval. I give up on trying to get an asterisk on each side of that variable. No form of escaping seems viable.

What does code-is-a-data have to do with security?!? Do not confuse an exposed `eval` with a compile-time homoiconicity.