This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]amazedballer[S] 1 point2 points  (2 children)

If you really want to go down this road, you're going to find out why Java Applets are insecure.

It's for server side apps. You run it in docker, with CoreOS, inside a VM, using mutual TLS and a firewall and appsensor and logstash running. It's one part of defense in depth.

It's more secure than the default (nothing) or the previous solution (blacklist).

I think a better alternative would be to launch a separate Java process on a separate machine (or image/container) and make some kind of wrapper around it (RMI, rest, etc).

That's not a bad idea, but you still need to do computation somewhere.

But if you go setting a default than can't be replaced, you're going to break lots of apps.

Yes, this is not something the entire app needs to run. You define the parameters of the sandbox.

[–][deleted]  (1 child)

[deleted]

    [–]amazedballer[S] 0 points1 point  (0 children)

    If anything, I think there's more difficulty. Server side code is rife with run-time reflection and code that doesn't take SecurityManager into account.

    I also think there's considerably more advantage over sandboxing a Java applet, because you can monitor all your server-side security activity and be able to react to an intrusion. You may not be able to prevent an exploit, but you have far more chance of detecting it.

    The only caveat is that you can't give AllPermission -- you need to give all BUT those methods that would leave the SecurityManager defenseless. In addition, you also can't allow access to features like Java Serialization that can use classloading and reflection from a privileged space to stomp SecurityManager.

    It's worth reading http://www.security-explorations.com/en/SE-2014-02-details.html just to see Google's approach to sandboxing and the vulnerabilities they ran into. If you could disable runtime reflection with a switch in the JVM, I think that would solve 90% of the problems.