Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: