On Apr 18, 2014, at 5:50 PM, Stuart Douglas <stuart.w.douglas(a)gmail.com&gt; wrote: Enabling the security manager by default is a terrible idea.

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 On Sat, Apr 19, 2014 at 1:53 AM, Jason T. Greene <jgreene(a)redhat.com <mailto:jgreene@redhat.com>> wrote: Sent from my iPhone > On Apr 18, 2014, at 5:50 PM, Stuart Douglas <stuart.w.douglas(a)gmail.com <mailto:stuart.w.douglas@gmail.com>> wrote: > > > Enabling the security manager by default is a terrible idea. +1000 ___________

The Java Security Manager makes a lot of sense also on the server side when you are building component based software and want for instance to ensure that some components are eligible to access some data and others are not. If you can ensure that most components are not able to access certain sensitive data then you can skip them in security audits and that’s a great win!

From: "arjan tijms" <arjan.tijms(a)gmail.com&gt; To: "Jason T. Greene" <jgreene(a)redhat.com&gt; 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

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&gt; > To: "Jason T. Greene" <jgreene(a)redhat.com&gt; > 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 _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Hi, On Wed, Apr 23, 2014 at 3:38 PM, Bill Burke <bburke(a)redhat.com&gt; 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. I'm a big fan of this view. I know that originally the AS may have been seen as a kind of OS for server apps, but in practice this just hasn't worked out. The protection model of the OS with its isolating processes is just much more powerful. Running a single app per AS gives you better protection, even more if each AS runs inside its own virtual server (which makes it even easier to limit the CPU usage of individual apps). Additionally, a lot of problems associated with updating either the JVM, the entire AS, or one or more libraries of the AS just go away in the one-app-per-AS setup. Adam Bien wrote a good article about this: http://adam-bien.com/roller/abien/entry/why_not_one_application_per I think Red Hat/JBoss shares the same belief. I mean, why else would OpenShift use SELinux to isolate apps and not just run a bunch of them on a single JBoss AS?

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&gt; >> To: "Jason T. Greene" <jgreene(a)redhat.com&gt; >> 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 > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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&gt; 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&gt; >>>> To: "Jason T. Greene" <jgreene(a)redhat.com&gt; >>>> 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 >>>> _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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(a)redhat.com <mailto:Anil.Saldhana@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(a)redhat.com <mailto:bburke@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 <mailto:arjan.tijms@gmail.com>> >>>> To: "Jason T. Greene" <jgreene(a)redhat.com <mailto:jgreene@redhat.com>> >>>> Cc: wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@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 >>>>

Andrew Haley, Andrew Dinn and myself looked at a multi-tenat JVM solution that addressed the isolation issues using byte code level traps very much like the modern virtual machines do. It had a nice api for the user space/JVM kernel transitions, but at the end of the day, the concern over unknowable security issues relating to very low level issues such as information leakage across isolated containers due to the shared memory, classes, etc. was deemed to large of a problem for us to handle with our JVM level resources. Multiple JVMs in the cloud are a huge waste of resources that needs to be addressed to make it cost effective. ----- Original Message ----- From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; To: wildfly-dev(a)lists.jboss.org Sent: Thursday, April 24, 2014 9:40:14 AM Subject: Re: [wildfly-dev] my 2 cents on Security Manager discussion 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(a)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(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 >>>> >>>>

From: "arjan tijms" <arjan.tijms(a)gmail.com&gt; To: "Josef Cacek" <jcacek(a)redhat.com&gt; Cc: "WildFly Dev" <wildfly-dev(a)lists.jboss.org&gt; Sent: Wednesday, April 23, 2014 7:54:43 AM Subject: Re: [wildfly-dev] my 2 cents on Security Manager discussion

Hi,

On Wed, Apr 23, 2014 at 2:40 PM, Josef Cacek < jcacek(a)redhat.com > wrote:

> 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)? > * ...

It's not about wanting that or not wanting it I think. It's about the question if you run code that you trust or not on your server. If you don't trust your code, then you may indeed be tempted to put up guards against calling System.exit(), etc.

But...

In practice, in at least my experience, it just doesn't happen a lot if ever that you run untrusted code on a server.

In the majority of the cases the code I and my team deploy is the code that I and my team have written. We don't need to protect ourselves against calling System.exit(). If we suspect that a library that we use would be potentially malicious enough that it called System.exit() or did other nasty things then we just don't use it.

Since in the overwhelming majority of cases you totally control the code and all its dependencies on the server, there's no need to put guards in place. Either you trust the code and use it, or you don't trust the code and then don't use it.

As soon as someone would feel a need to put a guard in place, then it means the code isn't fully trusted and thus the decision not to use that code has already been made IMHO.

And particularly about the "users" in "to allow users/deployed-apps/3rd-party-libs": the permissions you mentioned are all *code level* permissions. Users aren't code, but interact with your system via its UI. So naturally you need a lot of user level permissions, but this is something else than code level ones.

Kind regards, Arjan

_______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Late to the discussion, but this came up in conversations at DevNation. Are you sure you guys want to fully enable the Java security manager going forward? Jboss has been around for, what 14 years now? How many users/customers actually desire the Java Security Manager to be on by default? Could it be a possibility that the majority of our customers/users might freak out if they found that all of a sudden the Java Security Manager is on when it has been off the last 14 years? I don't know. Just seems to me that there is a lot of other cool ideas that you guys have been discussing that might be more interesting to wildfly's user base.

Late to the discussion, but this came up in conversations at DevNation. Are you sure you guys want to fully enable the Java security manager going forward? Jboss has been around for, what 14 years now? How many users/customers actually desire the Java Security Manager to be on by default? Could it be a possibility that the majority of our customers/users might freak out if they found that all of a sudden the Java Security Manager is on when it has been off the last 14 years? I don't know. Just seems to me that there is a lot of other cool ideas that you guys have been discussing that might be more interesting to wildfly's user base.