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> 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>
>>> To: "Jason T. Greene" <jgreene(a)redhat.com>
>>> Cc: wildfly-dev(a)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
>>>