[wildfly-dev] my 2 cents on Security Manager discussion

[Jim McGuinness]

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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140419/951450ea/attachment.html