4 ms·

Android aside, the use of JVM might offer a better alternative (because of bytecode validation). One way to achieve security is to enforce what an application/

Android aside, the use of JVM might offer a better alternative (because of bytecode validation). One way to achieve security is to enforce what an application/process can do is via specialized interfaces. For example, java.io.File will only see a virtual application filesystem, and one would need to grant special permissions (via a different interface) for file access outside of the app sandbox. These permissions should be controlled (and audited) by the user. Possibly at more levels than currently (blocked/allowed always/while running).

monocasa 7y ago
That was tried by the sun JVM, and worked until they tacked on reflection. Then there was just too many ways to break the sandbox when the sandbox is implemented just like your code is and you've got a mechanism for doing brain surgery on the process. Every time they'd fix a applet sandbox escape two more exploits would pop up.
- java-man 7y ago
  Security must be the primary design goal, at least right now. I don't think the way Sun implemented permissions in java offers enough protection.
  - monocasa 7y ago
    I mean, security was absolutely a primary design of java applets. It's just that implementing your sandbox at the same level as untrusted code is a really poor choice.
    - java-man 7y ago
      Did you just proved my thesis? ;-) The devil is in details, in other words, it matters how the sandbox/isolation is implemented. I would expect this: some malicious code requests a service object from the OS. An implementation is returned, but if no permission is granted by the user, the said implementation does nothing. There should be no data in the service object that can be used to glean any information about the internal state. The only thing that can be detected in this design is that the service object does nothing (and even then, perhaps, it is possible to emulate the service behavior such that the code thinks everything is fine). What do you think of that?

monocasa 7y ago

That was tried by the sun JVM, and worked until they tacked on reflection. Then there was just too many ways to break the sandbox when the sandbox is implemented just like your code is and you've got a mechanism for doing brain surgery on the process. Every time they'd fix a applet sandbox escape two more exploits would pop up.

java-man 7y ago
Security must be the primary design goal, at least right now. I don't think the way Sun implemented permissions in java offers enough protection.
- monocasa 7y ago
  I mean, security was absolutely a primary design of java applets. It's just that implementing your sandbox at the same level as untrusted code is a really poor choice.
  - java-man 7y ago
    Did you just proved my thesis? ;-) The devil is in details, in other words, it matters how the sandbox/isolation is implemented. I would expect this: some malicious code requests a service object from the OS. An implementation is returned, but if no permission is granted by the user, the said implementation does nothing. There should be no data in the service object that can be used to glean any information about the internal state. The only thing that can be detected in this design is that the service object does nothing (and even then, perhaps, it is possible to emulate the service behavior such that the code thinks everything is fine). What do you think of that?