jsr342-experts@javaee-spec.java.net

[jsr342-experts] Re: security manager requirements in Java EE

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Thu, 08 Mar 2012 17:40:15 -0800

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
>>>
>>> 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.
>>
>