> From: Bill Shannon [mailto:bill.shannon_at_oracle.com]
> Sent: 18 February 2012 04:25
> To: jsr342-experts_at_javaee-spec.java.net
> Subject: [jsr342-experts] Re: security manager requirements in Java EE
>
> Deepak Anupalli wrote on 02/16/12 23:06:
> >> ***** Would you support a requirement to be able to run
> >> ***** applications with a restricted set of permissions?
> >
> > Most App Servers do have Java Policy configuration and run the Server
> > VM in a security sandbox. AFAIK, Java EE TCK verifies an existing set
> > of Java EE security permissions defined in the Java EE platform
specification
> EE.6.2.3.
> >
> > How different is this new set going to be from the existing one?
>
> The current set of security permissions described in the platform spec is
the
> minimal set of permissions that an *application* should expect to have. A
> Java EE product may give an application more permissions than that. As
> currently written, a Java EE product can meet the requirements by giving
all
> applications all permissions.
>
> What I'm asking for above is whether there should be a requirement that
> application servers be able to restrict the permissions to less than all
> permissions. How exactly to specify the set you must be able to restrict
> applications to is unclear, but it certainly wouldn't be smaller than the
> minimal set currently defined.
Sounds fair to have a contract for supporting the intended Policy
configuration (which is definitely a subset of ALL permissions). I'm sure
most Java EE products would have already been restricting the permission set
for applications to run. It makes more sense to hear from others, to
understand security policy config of other products.
>
> >> 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?
> >
> > This is an area with possible impedance mismatch between Paas Provider
> > and the PaaS Customer in terms of expected configuration. But, I
> > strongly feel we should leave it out to the Paas Provider to figure
> > out contract for enforcing required security policy for their Customers.
>
> The PaaS Provider should decide what permissions it's willing to give to
> applications. The question here is whether there should be a way for
> applications to declare what permissions they need to run, so that the
PaaS
> Provider can make sure to give it those permissions, or reject the
> deployment if it's unwilling to give it those permissions.
Does that pave way for new security permission metadata which will be
bundled along with the application?
>
> > Just some thoughts, not sure if we talked about this earlier. Can the
> > same VM/Instance host applications belonging to different tenants with
> > separate set of VM/platform/vendor-specific configurations?
>
> We won't require support for that, but we intend to allow it.
Thanks for clarifying this.
>
> > To elaborate a little bit, each application can have an entirely
> > different memory footprint OR for web applications tuning parameters
> > like socket pools, thread pools, buffer sizes, denial of service(DOS)
> > etc. could be entirely different. When we are talking about
> > multi-tenancy at platform, can these applications with different
> > config requirements be provisioned on the same containers?
>
> Running such applications from different tenants is currently a challenge
> given the limited ability to enforce such resource restrictions. We
expect
> that most products will run different tenants in different JVM instances,
but
> we don't want to prevent someone from producing a product capable of
> doing this in a single JVM.
>
> > If not, what's the guarantee an application be provisioned or deployed
> > on the PaaS platform. In order to truly envision multi-tenancy of the
> > platform, there should be some guarantee on the
> > environment/configuration a PaaS provider makes to its customers.
>
> Mostly that's a quality of service issue. Choose a PaaS provider that
gives you
> the guarantees you need. Do you need dedicated hardware? Are you willing
> to run in a virtualized environment that might be shared with your
> competitors? Are you running in a "private cloud" where you can simply
fire
> people who misuse your resources? There's a wide range of needs and
> possible products. We're trying to define a programming model that will
> work for all of them. In some cases we're trying to define a way for the
> application to communicate its needs to the PaaS product so that there
aren't
> surprises at runtime.
I see that resource metadata has not only standardized resource
configuration needed for an application to deploy on a PaaS platform, but
also a key artefact for the PaaS provider to comply and create environment
required for the application.
Can similar standardization be achieved for container or server environment
configuration? No. Then, how does the application submitter translate this
requirement? Eventually this would force him to get access to the Server
instance or JVM and configure the Java EE product configuration himself, Do
we really want PaaS user to take this route?
On the other hand looking from the PaaS vendor perspective, each vendor
could come up with a non-standard Server configuration template, which an
application submitter can bundle along with the application. This artefact
serves the purpose of setting up the required environment for the
application or reject the application entirely if the PaaS provider cannot
meet the needs. I guess from the Java EE PaaS standpoint we need to favour
this approach.
-Deepak