3 ms·
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 t
by 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 agoYes. 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 agoSure. 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.