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

Thu Apr 24 08:49:07 EDT 2014

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 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
>      >>>>
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
- DML