Deepak Anupalli wrote on 02/20/12 06:04:
>> 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.
Yes, I'd definitely like to hear from others! :-)
>>>> 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?
Yes, that's the intent.
>>> 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?
No, that's not the intent. Some PaaS products simply won't provide any
way to configure these details - you get what you get and that's it.
Others will provide limited configurability through product-specific
mechanisms.
> 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.
As we gain more experience with what real products do in this area, we
might find things we could standardize.