jsr342-experts@javaee-spec.java.net

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

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Wed, 14 Mar 2012 10:53:32 -0700

Since the little feedback we got seemed to support the proposals below,
we've prepared a more complete proposal for your review. Let us know
what you think.

http://java.net/projects/javaee-spec/downloads/download/secmgr-permission-config-ee7-proposal.pdf

Thanks.

Bill Shannon wrote on 03/08/12 16:01:
> 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.
>