3 ms·

It's a generic problem in computing. Reducing the language set only changes the difficulty and does not eliminate it simply by the Nature of Turing machines.

• roywiggins 10y ago
  Running a Turing-complete language in a jail is entirely possible. If you don't give it access to, say, webcam APIs the you can be sure it won't turn the webcam on unless there's a bug in the jail. Of course, proving the jail is secure is awfully difficult but you can at least analyze it at your leisure, and you only have to do it once. I don't know if this is possible as a practical matter but the halting problem doesn't exclude the possibility.
  • tscs37 10y ago
    I'm not aware of any perfect jail. Even then studies have shown that a simple memory error can lead to breakout.
    • alkonaut 10y ago
      We already hope that the Turing Complete normal js doesn't access our files - so hopefully what this aims to do is simpler
• alkonaut 10y ago
  Just because a language is turing complete doesnt't mean it can do anything. It might still have a limited api or run in a sandbox without access to the data we wish to protect. JS is already turing complete but we are pretty sure websites don't upload our local files to strangers) short of using vulnerabilities). I don't understand how it would be hard to invent a subset of JS small enough to be possible to validate.
  • tscs37 10y ago
    Because even if the language was perfectly validated and the jail in which it runs is perfectly sound, you can still execute malicious code by breaking out of the jail via memory errors.
    • alkonaut 10y ago
      Yes. But we assume (and hope) that sandboxes and limited API surfaces actually work. That's how browser js or the AppStore works. If Apple decided that apps shouldn't see gps data tomorrow, they could just remove it from the data available to apps, and that would in fact work. The same should work for a subset of js if one is careful.
      • tscs37 10y ago
        >that sandboxes and limited API surfaces actually work While this is not a bad start, assuming they work is a bad option from a security standpoint. You should be pessimistic and always assume the sandbox will be broken and the API abused. Then you plan for that. Assuming nobody will ever hack your product because it's perfect is harmful for any security product. Period.
        • alkonaut 10y ago
          Sure. But we are talking about a system that already is in a sandbox, and that already has a limited API surface. If that doesn't work then we are all screwed anyway. I don't see it as a reason for not pursuing the idea of further shrinking the sandbox. A smaller language and smaller sandbox should theoretically be easier to validate than large langage running in a large sandbox.