Consider also that there are currently *zero* viable multi-tenant JVMs
in existence - just some experimental work, that I know of at least.
Using a JVM per application combined with OS-level safeguards is far
simpler (and more capable) for the small minority of users who feel the
need to run untrusted code on their system.
On 04/24/2014 02:49 AM, Przemyslaw Bielicki wrote:
Do we really need multi-tenancy in server-side Java?
We all know that Java has a serious limitation of max heap size - 16GB
is the max I've ever seen (used by Hadoop name node). Now, consider
modern commodity hardware that ships with 500GB - 1000GB of RAM. Let's
assume that your application's max heap usage is really 16GB and another
16GB off-heap memory (in case of mentioned name node it can be up to max
RAM available if your application uses IO heavily and it can be cached
by the OS). My humble calculations let me think that on such machine we
can easily run 16 - 32 separate JVMs (considering RAM only, CPU is
another story).
Knowing this, I don't think JVM can be a serious host of multi-tenant
applications in the cloud. I rather see JVM instance per application and
in such case we don't have security issues and SM is not needed. If one
application is dead (e.g. malicious System.exit, JVM core dump, etc.)
all the rest is safe.
On Wed, Apr 23, 2014 at 6:00 PM, Anil Saldhana <Anil.Saldhana(a)redhat.com
<mailto:Anil.Saldhana@redhat.com>> wrote:
Well explained, Jason. I feel the JVM needs to be a true multi-tenant
system to be a serious contender in the multi-tenant cloud env. I doubt
any efforts are being made at the VM level.
On 04/23/2014 09:10 AM, Jason Greene wrote:
> Right. An operating system is able to segment code by using page
mapping and traps. Each process gets a dedicated memory area that
another process can’t access at a very low level (without special
permissions). The JVM + SM on the other hand relies on protection at
a higher level. Fundamentally the entire JVM memory area is shared
between all code. The only thing that prevents it is lots of
security checks on every possible method that might leak a
reference. So the fundamental flaw is that the SM requires a perfect
policy, and is essentially trust-by-default. If a developer forgets
to add a check, then a vulnerability is possible. This happens
frequently, even in the JDK itself (hence the multiple CVEs)
>
> The only way the JVM could fix this, is if it introduced real
multi-tenancy at the lowest levels. You would have to operate
similar to an OS and assign blocks of heap to a particular app, and
allow sharing for certain “safe” things like code pages tied to
class implementations.
>
> On Apr 23, 2014, at 8:38 AM, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
>
>> As much as we like to think the app server is an operating
system, it
>> isn't. The app server isn't a place where untrusted apps run.
>>
>> On 4/23/2014 8:40 AM, Josef Cacek wrote:
>>> Hi Arjan,
>>>
>>> let me give you few examples. Do you really want to allow
users/deployed-apps/3rd-party-libs
>>>
>>> * call System.exit()?
>>> * change behavior of the whole JVM by changing some system
properties (keystores and truststores for instance)?
>>> * use reflection to read/change private data (caches, etc)?
>>> * access the filesystem (e.g. rewrite the WildFly
configuration files)?
>>> * ...
>>>
>>> If the answer is always yes, then you don't need the JSM I think.
>>>
>>> But if you care what can do the parts of code which you don't
have under full control, then you should really use the Java
Security Manager.
>>>
>>> Best regards,
>>>
>>> -- Josef
>>>
>>> ----- Original Message -----
>>>> From: "arjan tijms" <arjan.tijms(a)gmail.com
<mailto:arjan.tijms@gmail.com>>
>>>> To: "Jason T. Greene" <jgreene(a)redhat.com
<mailto:jgreene@redhat.com>>
>>>> Cc: wildfly-dev(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
>>>> Sent: Saturday, April 19, 2014 7:43:24 PM
>>>> Subject: Re: [wildfly-dev] my 2 cents on Security Manager
discussion
>>>>
>>>> Hi,
>>>>
>>>> Just wondering, but what is the primary use case for a
security manager
>>>> server side?
>>>>
>>>> While the model obviously makes sense for Applets and Webstart
where
>>>> untrusted code is executed on the user's machine, I found it
to be extremely
>>>> rare for a server to run untrusted code. In fact, I don't
think I've ever
>>>> seen this situation.
>>>>
>>>> There's maybe a case to prevent privilege escalation in case
of a legitimate
>>>> app being hacked, but in practice it doesn't look like a
security manager is
>>>> really being used a lot for that, is it? Instead the default
thing to do
>>>> there seems to be to run the AS under a user with limited
rights on the host
>>>> OS and/or use things like SELinix or Virtual Servers (e.g.
XEN) to isolate
>>>> the complete AS.
>>>>
>>>> Kind regards,
>>>> Arjan Tijms
>>>>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev