[wildfly-dev] my 2 cents on Security Manager discussion

[Przemyslaw Bielicki]

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 at 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 at 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 at gmail.com>
> >>>> To: "Jason T. Greene" <jgreene at redhat.com>
> >>>> Cc: wildfly-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140424/50815d85/attachment.html