Jevgeni Kabanov wrote on 03/08/12 22:07:
> I can share a few ideas on this.
>
> JRebel is one tool that obviously requires full access to the JVM capabilities,
> and we've been running it on a wide variety of containers for a while. One of
> them, that ships with a restrictive security policy and is a JVM-based PaaS is
> Google App Engine. Or rather it's the GAE's development version, which is a
> Jetty server with a lot of custom modifications, including a very restrictive
> custom security policy that blocks access to many APIs, like the files system,
> sockets, and a lot of other stuff.
>
> Basically, what happens in such an environment is that the majority of Java
> frameworks breaks. Some of them will degrade gracefully, but the majority of
> code in Java is written with no concern for security policies and will not
> survive such restrictions (e.g. creating class loaders and accessing private
> methods via reflection are two permissions that any framework will assume).
Right, this is why having a way to declare what permissions the
application requires will help.
An even more advanced possibility that we've considered is to require
support for signed jar files where you can declare what additional
permissions that signer should have. That would allow third party
frameworks to be vetted for security issues related to the additional
permissions they require, and platform vendors to choose to provide
those additional permissions only to those frameworks.
The technical part of that is easy, but changing people's behavior in
a way that would support this practice is much more difficult, and we're
not sure the world is ready for this yet.
> I believe that adding this requirement will change little in the practical sense
> -- this behavior in the community will only change if there are real, viable
> PaaS deployments with the security manager will become popular so that the
> framework developers would start taking them into account. Considering that GAE
> didn't become too popular with the community, I wonder how much was an issue
> that it was unpredictable what frameworks would work correctly on that platform.
We'd like to believe it's because it's not a "Java EE" platform! :-)
> I vote against the proposal, and suggest to avoid multi-tenancy inside a JVM in
> a PaaS environment. Although PaaS can use security sandboxing to give a measure
> of safety from attacks to the co-tenants on a JVM, it lacks any means to quota
> resources or isolate them in any meaningful way from memory leaks, crashes, CPU
> burn or any other resource abuses so it would be an inherently broken
> environment. The only reasonable way to do PaaS in Java is spin up a process per
> user and use system quotas and the separate address spaces to enforce isolation.
> Everything else is setting yourself up for a fall.
I understand, and I think that's what most people will do, until the JDK
provides some support for resource isolation. But we want to plan for that
future when the JDK does provide that support, and we don't want to reject
the possibility that in (e.g.) a private cloud environment these issues
will be more manageable.