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).
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.
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.
JK
On Friday, March 9, 2012, Bill Shannon wrote:
> For people who only want to watch, we have the "users" mailing list.
> I'm expecting people on the expert group to actively declare their
> position. A simple "+1" is fine.
>
>
> Jeff Genender wrote on 03/08/2012 04:11 PM:
>
>> Silence is what is called lazy consensus ;-)
>>
>> Jeff
>>
>>
>> On Mar 8, 2012, at 4:01 PM, Bill Shannon wrote:
>>
>> It's been almost a month and we've gotten very little feedback on the
>>> questions I asked below. I hope this isn't an indication that this
>>> expert group has little interest in security issues. :-(
>>>
>>> Given this lack of feedback, we're assuming *all* of you support *all*
>>> of the proposals below. We'll be moving forward accordingly.
>>>
>>> Thanks.
>>>
>>> Bill Shannon wrote on 02/10/2012 02:01 PM:
>>>
>>>> Security has always been a key part of the Java EE platform.
>>>> From the beginning we defined the Java security permissions
>>>> that an application should expect to have, and we expected
>>>> that application servers would want to control what permissions
>>>> applications should have. Several releases ago we clarified
>>>> the requirements so that application servers may run without a
>>>> security manager. This was commonly used in development environments,
>>>> and in non-Java EE application servers such as Tomcat.
>>>>
>>>> Unfortunately, what we failed to do was to make it clear that
>>>> Java EE applications servers were also required to be able to
>>>> run *with* a security manager, and to be able to enforce Java
>>>> security permissions.
>>>>
>>>> ***** Unless there are objections, we intend to make this
>>>> ***** requirement explicit in the EE 7 spec.
>>>>
>>>>
>>>> One of the reasons this issue comes up is that some library and
>>>> framework developers seem to assume that they can do anything
>>>> they want with any Java API. Users then complain when these
>>>> libraries or frameworks don't work in an application server that
>>>> uses a security manager.
>>>>
>>>> A degenerate way that an application server could meet the requirement
>>>> to be able to run with a security manager would be to simply grant
>>>> all applications all permissions all the time. Obviously that
>>>> wouldn't address the core problem. Thus, we believe we also need
>>>> a clear requirement that the application server be able to
>>>> *restrict* the set of permissions granted to an application.
>>>>
>>>> Defining a requirement in this area is a bit tricky. While it
>>>> might seem attractive to require that an application server be
>>>> able to run applications with *only* the minimum permissions
>>>> defined in the spec, it's possible that there could be product
>>>> specific (non-standard) permissions that are needed. Still,
>>>> it seems like it would be good to define some boundaries here.
>>>>
>>>> ***** Would you support a requirement to be able to run
>>>> ***** applications with a restricted set of permissions?
>>>>
>>>>
>>>> We think it's especially likely that a Java EE cloud product
>>>> will use a security manager to maintain control over the
>>>> operational environment. Remember, our target is PaaS, not
>>>> Middleware over IaaS:
>>>> http://blogs.oracle.com/**rezashafii/entry/paas_is_not_**
>>>> middleware_over<http://blogs.oracle.com/rezashafii/entry/paas_is_not_middleware_over>
>>>>
>>>> In a true PaaS environment, application permissions are likely
>>>> to be restricted to only what's needed. In such an environment,
>>>> it may be useful to know if the application needs any permissions
>>>> beyond the minimum that the platform spec guarantees.
>>>>
>>>> Something we've been considering for quite some time is to provide
>>>> a way for an application to include a list of these additional
>>>> permissions it needs. The platform implementation could then
>>>> evaluate these permissions and ensure that the application is
>>>> granted what it needs, or reject deployment of the application.
>>>>
>>>> ***** Would you support including such a capability in Java EE?
>>>>
>>>>
>>>> Other than the first item above, we're not sure how many of these
>>>> items we can address for EE 7, but we wanted to see if there was
>>>> support in principle for these items before we moved forward.
>>>>
>>>> Let us know what you think.
>>>>
>>>
>>>
>>
>