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