<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Thanks for your excellent
      observations.&nbsp; Answers inline.<br>
      <br>
      On 04/24/2014 02:49 AM, Przemyslaw Bielicki wrote:<br>
    </div>
    <blockquote
cite="mid:CAMvdueDTh4zSEwj+PynSB-3w_kzhdi2Z39pEr7nfYVxdaVGKsQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">Do we really need multi-tenancy in server-side
        Java?<br>
        <br>
      </div>
    </blockquote>
    It may be necessary for the following reasons:<br>
    - save memory wastage (as outlined by Jason)<br>
    - 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)<br>
    &nbsp;&nbsp; * 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) <br>
    <br>
    <blockquote
cite="mid:CAMvdueDTh4zSEwj+PynSB-3w_kzhdi2Z39pEr7nfYVxdaVGKsQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">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).<br>
        <br>
        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&nbsp;
        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.<br>
      </div>
    </blockquote>
    Solving the system exit or core dump issues is really a tall order
    to climb for multi-tenant JVMs.&nbsp; The complexity/work involved
    probably outweighs the benefits.<br>
    <br>
    I am leaning now toward a single app/single JVM strategy.<br>
    <blockquote
cite="mid:CAMvdueDTh4zSEwj+PynSB-3w_kzhdi2Z39pEr7nfYVxdaVGKsQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On Wed, Apr 23, 2014 at 6:00 PM, Anil
          Saldhana <span dir="ltr">&lt;<a moz-do-not-send="true"
              href="mailto:Anil.Saldhana@redhat.com" target="_blank">Anil.Saldhana@redhat.com</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">Well
            explained, Jason. &nbsp;I feel the JVM needs to be a true
            multi-tenant<br>
            system to be a serious contender in the multi-tenant cloud
            env. I doubt<br>
            any efforts are being made at the VM level.<br>
            <div class="HOEnZb">
              <div class="h5"><br>
                On 04/23/2014 09:10 AM, Jason Greene wrote:<br>
                &gt; 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&#8217;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)<br>
                &gt;<br>
                &gt; 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 &#8220;safe&#8221; things like code pages tied to class
                implementations.<br>
                &gt;<br>
                &gt; On Apr 23, 2014, at 8:38 AM, Bill Burke &lt;<a
                  moz-do-not-send="true" href="mailto:bburke@redhat.com">bburke@redhat.com</a>&gt;
                wrote:<br>
                &gt;<br>
                &gt;&gt; As much as we like to think the app server is
                an operating system, it<br>
                &gt;&gt; isn't. &nbsp;The app server isn't a place where
                untrusted apps run.<br>
                &gt;&gt;<br>
                &gt;&gt; On 4/23/2014 8:40 AM, Josef Cacek wrote:<br>
                &gt;&gt;&gt; Hi Arjan,<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; let me give you few examples. Do you really
                want to allow users/deployed-apps/3rd-party-libs<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; &nbsp; * call System.exit()?<br>
                &gt;&gt;&gt; &nbsp; * change behavior of the whole JVM by
                changing some system properties (keystores and
                truststores for instance)?<br>
                &gt;&gt;&gt; &nbsp; * use reflection to read/change private
                data (caches, etc)?<br>
                &gt;&gt;&gt; &nbsp; * access the filesystem (e.g. rewrite the
                WildFly configuration files)?<br>
                &gt;&gt;&gt; &nbsp; * ...<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; If the answer is always yes, then you don't
                need the JSM I think.<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; 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.<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; Best regards,<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; -- Josef<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; ----- Original Message -----<br>
                &gt;&gt;&gt;&gt; From: "arjan tijms" &lt;<a
                  moz-do-not-send="true"
                  href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>&gt;<br>
                &gt;&gt;&gt;&gt; To: "Jason T. Greene" &lt;<a
                  moz-do-not-send="true"
                  href="mailto:jgreene@redhat.com">jgreene@redhat.com</a>&gt;<br>
                &gt;&gt;&gt;&gt; Cc: <a moz-do-not-send="true"
                  href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
                &gt;&gt;&gt;&gt; Sent: Saturday, April 19, 2014 7:43:24
                PM<br>
                &gt;&gt;&gt;&gt; Subject: Re: [wildfly-dev] my 2 cents
                on Security Manager discussion<br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; Hi,<br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; Just wondering, but what is the primary
                use case for a security manager<br>
                &gt;&gt;&gt;&gt; server side?<br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; While the model obviously makes sense
                for Applets and Webstart where<br>
                &gt;&gt;&gt;&gt; untrusted code is executed on the
                user's machine, I found it to be extremely<br>
                &gt;&gt;&gt;&gt; rare for a server to run untrusted
                code. In fact, I don't think I've ever<br>
                &gt;&gt;&gt;&gt; seen this situation.<br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; There's maybe a case to prevent
                privilege escalation in case of a legitimate<br>
                &gt;&gt;&gt;&gt; app being hacked, but in practice it
                doesn't look like a security manager is<br>
                &gt;&gt;&gt;&gt; really being used a lot for that, is
                it? Instead the default thing to do<br>
                &gt;&gt;&gt;&gt; there seems to be to run the AS under a
                user with limited rights on the host<br>
                &gt;&gt;&gt;&gt; OS and/or use things like SELinix or
                Virtual Servers (e.g. XEN) to isolate<br>
                &gt;&gt;&gt;&gt; the complete AS.<br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; Kind regards,<br>
                &gt;&gt;&gt;&gt; Arjan Tijms<br>
                &gt;&gt;&gt;&gt;<br>
              </div>
            </div>
          </blockquote>
        </div>
      </div>
    </blockquote>
    &nbsp;
  </body>
</html>