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 ;-)
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.
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
***** 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:
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.
[javaee-spec users] [jsr342-experts] Re: security manager requirements in Java EE
|Jason T. Greene||03/09/2012|