Java CodeSource Based Security Model

We have shipped JBoss Application Server v5.0 based on VFS (Virtual File System) semantics in the microcontainer. To get the Application Server to run under a Java Security Manager while trying to retain the default policy implementation in the JDK, I went through a lot of troubling times as evident from this design forum thread. There was a lot of finger pointing, crying and swearing in public involved. Equally there were enough emails flying across in internal mailing list(s) with the designers of the JBoss microcontainer.

Well some of the issues are being described by my friend, Dennis Pilipchuck (Enterprise Security Architect at BEA/Oracle) in his java.net article titled:
"Pitfalls of the Java Permissions Model"

========================================================================================

Pitfalls of the Java Permissions Model by Denis Pilipchuk -- Is Java a good choice for creating applications with configurable security? Denis Pilipchuk argues that Java's permissions-based security model is a relic of its browser days and lacks the configurability, expressiveness, and efficiency that enterprise Java developers need. In this article, he looks at the problems of the permissions model and considers some alternatives.

===========================================================================

The CodeSource URL based Java Security Model is outdated. It has never been updated since the browser-applet security days. Li Gong architected the model, then moved to Microsoft and then eventually to Mozilla Foundation (his journey has taken a decade - but the Java permissions model has neither seen any updates nor seen any desire for alternatives). So this article from Dennis seems like a coincidence in blessing. So we are not alone.

We were able to ship JBoss Application Server v5.0.0.GA to run under a security manager with the following security manager policy as a template.
Java Security Manager Policy

What were our options?
a) Write a new policy provider - this would mean a new configuration format for the permissions and would actually shoo away any rare souls who want to run the application server under a security manager.
b) Try to somehow get the default jdk policy provider to recognize or tolerate vfs urls. We ended up with this option of having dummy URL protocol handlers in the JBoss AS bootstrap and at the time of policy enforcement, we would get the real vfs codesource urls read in as the vfs protocol handlers were in place.
c) Update the VFSClassLoaderPolicy implementation to return real urls of the code jars rather than the vfs urls. We do this now by default. It avoids the issues we had with the default policyfile implementation not understanding vfs urls. But we have kind of disabled the superior vfs urls for consideration by the security manager.

Complaints with the Java Permissions based Security Model:
1) CodeSource takes an URL instance and not URI.
2) No negative permissions that can be declaratively defined (Dennis talks about this too). JACC 1.1 has a work around in the actions of WebResourcePermission for "excluded" security constraints with a "!" prefix.
3) Stack frame checking across the call path is performance intensive. Privileged blocks in the source code mitigate the walking penalties but are so poorly understood (or avoided) by developers that an introduction can accidently be the source of security holes.

We really need updates to the Java Policy class/interface with alternative mechanisms and a need to foster usage of policy.implies (after the alternatives have been identified) in the enterprise source code before embarking on sensitive operations such as using reflection, getting the classloader etc.

I wonder about the following:
a) How many enterprise deployments run under a Java Security Manager? If not, without explicit policy.implies checks, everything is open.
b) How well Java privileged blocks are understood and adopted by enterprise developers and Framework writers?

JBoss portal previously attempted to define their access model based on JACC. They had to define their own permission classes and got it working. The developers found it extremely cumbersome. Currently they are working on adopting an XACML based approach using JBossXACML. In JBoss AS5, we provide a pluggable access control model where in you can plug and play access control stacks based on JACC, XACML or your custom implementation.

Related References:
Ted Neward's White Paper: http://www.tedneward.com/files/Papers/JavaPolicy/JavaPolicy.pdf

Additionally, improving the Java Security Model is not the responsibility of Sun alone. It has to be pushed for by the other VM vendors (IBM, BEA/JRockit etc) also. Maybe Dennis can ping his own JRockit folks?