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

Thu Apr 24 12:40:14 EDT 2014

Thanks for your excellent observations.  Answers inline.

On 04/24/2014 02:49 AM, Przemyslaw Bielicki wrote:
> Do we really need multi-tenancy in server-side Java?
>
It may be necessary for the following reasons:
- save memory wastage (as outlined by Jason)
- lower management of resources needs that comes with single 
application/singleVM/large box combination (management of ports is a big 
issue along with IP addresses)
    * Additionally if the app is fronted by Apache/NGinx or IIS with 
some proxy capabilities, then you deal with the proxy configuration 
(rewriting for multiple IPs/port combination due to app/vm)

> 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.
Solving the system exit or core dump issues is really a tall order to 
climb for multi-tenant JVMs.  The complexity/work involved probably 
outweighs the benefits.

I am leaning now toward a single app/single JVM strategy.
>
>
> On Wed, Apr 23, 2014 at 6:00 PM, Anil Saldhana 
> <Anil.Saldhana at redhat.com <mailto: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
>     <mailto: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
>     <mailto:arjan.tijms at gmail.com>>
>     >>>> To: "Jason T. Greene" <jgreene at redhat.com
>     <mailto:jgreene at redhat.com>>
>     >>>> Cc: wildfly-dev at lists.jboss.org
>     <mailto: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
>     >>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140424/a4d6d20b/attachment.html 