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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev