4 ms·

One of the aspects of the data-is-code and code-is-data duality that always bugged me surrounds security. Ever since we started embedded macro languages into d

One of the aspects of the data-is-code and code-is-data duality that always bugged me surrounds security. Ever since we started embedded macro languages into documents, there have been classes of security problems around them. Even before the web there were macro viruses in abundance, and running spreadsheets with macros embedded in them is still a dangerous proposition today. How does Lisp deal with the modern Writable Xor Executable philosophy? Or does it? Can a lispy program that exposes its lispyness to its users be secure (emacs, I'm looking at you)?

agumonkey 11y ago
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).
- brandmeyer 11y ago
  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.
  - agumonkey 11y ago
    I don't know what to Google ('lisp evaluator security' wasn't fruitful) but I'd love to see research on the subject.
    - bitwize 11y ago
      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/ http://mumble.net/~jar/pubs/secureos/
      - agumonkey 11y ago
        Ha, I knew it. Lambda the ultimate everything.
raphaelss 11y ago
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.
- seiji 11y ago
  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 https://developer.chrome.com/native-client
  - brandmeyer 11y ago
    I raise my right eyebrow of incredulity at the "actually secure" claim, considering that even Chrome regularly falls in contests like Pwn2Own.
    - seiji 11y ago
      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-privacy 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.
- btilly 11y ago
  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.
mbrock 11y ago
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.
kyllo 11y ago
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...
acc54321 11y ago
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.
sklogic 11y ago
What does code-is-a-data have to do with security?!? Do not confuse an exposed `eval` with a compile-time homoiconicity.

agumonkey 11y ago

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

brandmeyer 11y ago
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.
- agumonkey 11y ago
  I don't know what to Google ('lisp evaluator security' wasn't fruitful) but I'd love to see research on the subject.
  - bitwize 11y ago
    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/ http://mumble.net/~jar/pubs/secureos/
    - agumonkey 11y ago
      Ha, I knew it. Lambda the ultimate everything.

raphaelss 11y ago

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.

seiji 11y ago
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 https://developer.chrome.com/native-client
- brandmeyer 11y ago
  I raise my right eyebrow of incredulity at the "actually secure" claim, considering that even Chrome regularly falls in contests like Pwn2Own.
  - seiji 11y ago
    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-privacy 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.
btilly 11y ago
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.

mbrock 11y ago

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.

kyllo 11y ago

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

acc54321 11y ago

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.

sklogic 11y ago

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