6:44 p.m.
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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
6:50 p.m.
Who is talking about enabling this by default?
What we have done is add a security manager subsystem that makes it very
easy to enable, and also implement the Java EE 7 standard permission.xml
descriptor to allow for a standard method of configuring permissions.
I have not heard anyone suggest this should be enabled by default, and I
don't think it ever will be for two main reasons:
- Performance: Enabling the security manager has a very noticeable
impact on performance. The checks are expensive and there are a lot of
them.
- Compatibility: Unless you have actually written your application
expecting it to be run under a security manager it almost certainly
won't work out of the box.
Enabling the security manager by default is a terrible idea.
Stuart
Bill Burke wrote:
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.
9:34 a.m.
On 04/18/2014 05:44 PM, Bill Burke wrote:
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.
For the record I think Java's security model is pretty terrible. Years
of really, really bad CVEs are pretty much all the evidence you need.
But security manager support is a part of Java EE now, as of 7 - and
worse yet it is inexorably tied up with several JAAS concepts, making it
a constant pain for us, as users want to be able to use JAAS even though
it is terrible and it itself is not formally a part of Java EE (it is,
after all, the only standard authentication client API). Given our
newer security initiatives, problems have arisen that we do have to
solve, and that means we have to think about how it impacts this stuff too.
So, this is why we've spent time dealing with this. There are tons of
other things I for one would rather be doing, believe me. :-)
--
- DML
1:20 p.m.
So from an external-to-Red-Hat perspective, leave the Java security manager
off as the wildfly default setting. While security continues to become more
important at the application level, I think you need to consider the
explicit/implicit objectives of wildfly: (a) provide an implementation of
the latest Java EE specs so developers/architects can work with it and
prepare for future work on projects and in production, and (b)
suggest/persuade non Red Hat customers to switch to JBoss. Turning on the
Java security manager in wildfly by default could really sour a lot of
developers/architects on Red Hat, not to mention wildfly. Consequently they
would most likely just switch to using glassfish.
But you want want to keep it easy and obvious to turn on the Java security
manager in wildfly.
Just my 2¢.
On Sat, Apr 19, 2014 at 8:34 AM, David M. Lloyd <david.lloyd(a)redhat.com>wrote:
On 04/18/2014 05:44 PM, Bill Burke wrote:
> 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.
For the record I think Java's security model is pretty terrible. Years
of really, really bad CVEs are pretty much all the evidence you need.
But security manager support is a part of Java EE now, as of 7 - and
worse yet it is inexorably tied up with several JAAS concepts, making it
a constant pain for us, as users want to be able to use JAAS even though
it is terrible and it itself is not formally a part of Java EE (it is,
after all, the only standard authentication client API). Given our
newer security initiatives, problems have arisen that we do have to
solve, and that means we have to think about how it impacts this stuff too.
So, this is why we've spent time dealing with this. There are tons of
other things I for one would rather be doing, believe me. :-)
--
- DML
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
1:43 p.m.
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> wrote:
Sent from my iPhone
> On Apr 18, 2014, at 5:50 PM, Stuart Douglas <stuart.w.douglas(a)gmail.com>
wrote:
>
>
> Enabling the security manager by default is a terrible idea.
+1000
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
4:46 p.m.
O, never mind then. I thought that's what you were discussing a few
weeks ago. I think others thought the same which is why I brought it up.
On 4/18/2014 6:50 PM, Stuart Douglas wrote:
Who is talking about enabling this by default?
What we have done is add a security manager subsystem that makes it very
easy to enable, and also implement the Java EE 7 standard permission.xml
descriptor to allow for a standard method of configuring permissions.
I have not heard anyone suggest this should be enabled by default, and I
don't think it ever will be for two main reasons:
- Performance: Enabling the security manager has a very noticeable
impact on performance. The checks are expensive and there are a lot of
them.
- Compatibility: Unless you have actually written your application
expecting it to be run under a security manager it almost certainly
won't work out of the box.
Enabling the security manager by default is a terrible idea.
Stuart
Bill Burke wrote:
> 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.
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
2:29 p.m.
On 04/19/2014 12:43 PM, arjan tijms wrote:
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.
I agree with what you are saying.
Unfortunately there are a handful of
users/developers/sys-admins who are required to run the JVM under the
JSM. Might be corporate policy or compliance etc.
Luckily they are a minority. They always pinpoint if there are any
particular permission failing under the JSM.
The JSM was really invented around the applet era and has really not
seen any major adaptation/overhaul for the s/w industry growth.
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
___________
2:35 p.m.
On 04/18/2014 05:44 PM, Bill Burke wrote:
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.
DML, Stefan Guilhen and I had a brainstorming session months ago before
the development of the security manager subsystem in WF8.
This session was mainly to address the permissions.xml requirement in EE7
https://blogs.oracle.com/SecuritEE/entry/java_ee_7_permission_declarations
During this session, we discussed the two options among many other
discussion items:
a) Enable Java Security Manager as default in WF8.
b) Create a custom JSM Policy implementation to replace the one in the JVM.
Both these options were immediately dropped as neither useful nor
necessary for
the WildFly community.
The Java Security Manager redesign happened around JDK 1.2 (applet era)
and has had no
major overhaul in the implementation. One change that may be useful is
the introduction of
a Policy SPI in JDK6:
http://docs.oracle.com/javase/6/docs/api/java/security/PolicySpi.html
JDK8 has limited doPrivileged:
http://openjdk.java.net/projects/jdk8/features#140
I agree with Stuart and Jason that enabling JSM by default is a terrible
idea.
2:54 a.m.
Hi,
Just want to throw in my other cent:
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!
Javas visibility is not capable of handling this.
Kind regards,
Robert
From: wildfly-dev-bounces(a)lists.jboss.org [mailto:wildfly-dev-bounces@lists.jboss.org] On
Behalf Of Anil Saldhana
Sent: Monday, April 21, 2014 8:29 PM
To: wildfly-dev(a)lists.jboss.org
Subject: Re: [wildfly-dev] my 2 cents on Security Manager discussion
On 04/19/2014 12:43 PM, arjan tijms wrote:
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.
I agree with what you are saying. Unfortunately there are a handful of
users/developers/sys-admins who are required to run the JVM under the JSM. Might be
corporate policy or compliance etc.
Luckily they are a minority. They always pinpoint if there are any particular permission
failing under the JSM.
The JSM was really invented around the applet era and has really not seen any major
adaptation/overhaul for the s/w industry growth.
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@redhat.com<mailto:jgreene@redhat.com>> wrote:
Sent from my iPhone
On Apr 18, 2014, at 5:50 PM, Stuart Douglas
<stuart.w.douglas@gmail.com<mailto:stuart.w.douglas@gmail.com>> wrote:
Enabling the security manager by default is a terrible idea.
+1000
___________
WINCOR NIXDORF International GmbH
Sitz der Gesellschaft: Paderborn
Registergericht Paderborn HRB 3507
Geschäftsführer: Eckard Heidloff (Vorsitzender), Dr. Jürgen Wunram (stellv. Vors.), Jens
Bohlen, Olaf Heyden
Vorsitzender des Aufsichtsrats: Dr. Alexander Dibelius
Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193
Diese E-Mail enthält vertrauliche Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.
This e-mail may contain confidential information.
If you are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail.
Any unauthorised copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.
6:17 a.m.
Hi,
On Tue, Apr 22, 2014 at 8:54 AM, Panzer, Robert <
Robert.Panzer(a)wincor-nixdorf.com> wrote:
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!
It does sound like a somewhat viable use case indeed, although in practice
it looks like few people walk that road (or maybe it are just my limited
amount of observations). What I did see (occasionally) happening in this
case is that people ran that single component that's capable of accessing
sensitive data in a separate JVM/virtual machine and then communicate with
it via a well-defined authenticated/secured interface.
That particular component is then protected by the OS' process model and
memory protection and the rest of the code doesn't suffer from the
performance degradation and coding complexities of the JSM.
If there's a LOT of communication with that particular component then I
guess running them both in the same JVM with the JSM enabled might
theoretically be better for performance, but I personally just haven't seen
this in practice.
Kind regards,
Arjan
7:09 a.m.
Sent from my iPhone
On 22 Apr 2014, at 16:54, "Panzer, Robert"
<Robert.Panzer(a)wincor-nixdorf.com> wrote:
Hi,
Just want to throw in my other cent:
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!
Javas visibility is not capable of handling this.
We are trying to make running under a security manager as easy as possible, just not by
default.
Stuart
Kind regards,
Robert
From: wildfly-dev-bounces(a)lists.jboss.org [mailto:wildfly-dev-bounces@lists.jboss.org] On
Behalf Of Anil Saldhana
Sent: Monday, April 21, 2014 8:29 PM
To: wildfly-dev(a)lists.jboss.org
Subject: Re: [wildfly-dev] my 2 cents on Security Manager discussion
On 04/19/2014 12:43 PM, arjan tijms wrote:
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.
I agree with what you are saying. Unfortunately there are a handful of
users/developers/sys-admins who are required to run the JVM under the JSM. Might be
corporate policy or compliance etc.
Luckily they are a minority. They always pinpoint if there are any particular permission
failing under the JSM.
The JSM was really invented around the applet era and has really not seen any major
adaptation/overhaul for the s/w industry growth.
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> wrote:
Sent from my iPhone
> On Apr 18, 2014, at 5:50 PM, Stuart Douglas <stuart.w.douglas(a)gmail.com>
wrote:
>
>
> Enabling the security manager by default is a terrible idea.
+1000
___________
WINCOR NIXDORF International GmbH
Sitz der Gesellschaft: Paderborn
Registergericht Paderborn HRB 3507
Geschäftsführer: Eckard Heidloff (Vorsitzender), Dr. Jürgen Wunram (stellv. Vors.), Jens
Bohlen, Olaf Heyden
Vorsitzender des Aufsichtsrats: Dr. Alexander Dibelius
Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193
Diese E-Mail enthält vertrauliche Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht
gestattet.
This e-mail may contain confidential information.
If you are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail.
Any unauthorised copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
8:40 a.m.
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
8:57 a.m.
At the same time, the sheer number of CVEs relating to sandbox
vulnerabilities and privilege escalations should give anyone pause, who
thinks to rely on an SM as a way to "safely" run untrusted code.
And an SM doesn't protect you from everything; untrusted code could, for
example, still lock threads into infinite, uninterruptible loops.
Finally, as I've said numerous times before, adding a security manager
has a performance cost - sometimes a *major* performance cost. You have
to balance all of these concerns against what your real requirements are
before you take the plunge.
On 04/23/2014 07: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
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
- DML
9:38 a.m.
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
_______________________________________________
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
9:54 a.m.
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
10:04 a.m.
----- Original Message -----
From: "arjan tijms" <arjan.tijms(a)gmail.com>
To: "Josef Cacek" <jcacek(a)redhat.com>
Cc: "WildFly Dev" <wildfly-dev(a)lists.jboss.org>
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.
I would add here, that you may start off
not trusting some code you want to use, but if that code is open source, then you can
audit that code for any malicious behavior. Open source libraries, as third-party
dependencies has become the norm too.
Andy
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
10:08 a.m.
Hi,
On Wed, Apr 23, 2014 at 3:38 PM, 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.
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?
Kind regards,
Arjan Tijms
10:10 a.m.
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
> _______________________________________________
> 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
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
10:34 a.m.
On Apr 23, 2014, at 9:08 AM, arjan tijms <arjan.tijms(a)gmail.com> wrote:
Hi,
On Wed, Apr 23, 2014 at 3:38 PM, 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.
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?
Yes that is our recommended security model, and yes thats precisely what we do on
OpenShift because otherwise one customer could potentially access another’s data, which
would be very very bad :)
We do hope that one day a multi-tenant JVM will come around, since it would reduce the
memory cost of multiple JVMs (base JVM heap + class code memory which ideally you could
share but can’t currently). Although this is only really a problem when you have thousands
of instances on a box (you are running a PAAS).
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
10:39 a.m.
On 4/23/2014 10:34 AM, Jason Greene wrote:
On Apr 23, 2014, at 9:08 AM, arjan tijms <arjan.tijms(a)gmail.com> wrote:
> Hi,
>
> On Wed, Apr 23, 2014 at 3:38 PM, 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.
>
> 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?
Yes that is our recommended security model, and yes thats precisely what we do on
OpenShift because otherwise one customer could potentially access another’s data, which
would be very very bad :)
We do hope that one day a multi-tenant JVM will come around, since it would reduce the
memory cost of multiple JVMs (base JVM heap + class code memory which ideally you could
share but can’t currently). Although this is only really a problem when you have thousands
of instances on a box (you are running a PAAS).
Just cross-process/cross-OS-VM shared jars would probably be really
huge. Not something we can really focus on in the middleware side of
development though.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
noon
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
>>>
3:49 a.m.
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>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
>>>>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
8:49 a.m.
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(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
>>>>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
- DML
12:40 p.m.
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 <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
>>>>
1:13 p.m.
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>
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
>>>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
1:17 p.m.
Well - anytime you have shared memory - you are going to need additional
checks/boundaries lest you have the hearbleed/openssl issue. It is a
tall order.
On 04/24/2014 12:13 PM, Scott Stark wrote:
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>
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
>>>>
>>>>
3652
days inactive
3658
days old
26 comments
13 participants
participants (13)
-
Andrig Miller -
Anil Saldhana -
arjan tijms -
Bill Burke -
David M. Lloyd -
Jason Greene -
Jason T. Greene -
Jim McGuinness -
Josef Cacek -
Panzer, Robert -
Przemyslaw Bielicki -
Scott Stark -
Stuart Douglas