excalibur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leif Mortenson <leifli...@tanukisoftware.com>
Subject Fortress. BCEL and Security Managers
Date Fri, 10 Sep 2004 05:24:36 GMT
I went in and upgraded an application this week which makes use of an
internal RMI
server. Because RMI requires that a SecurityManager be registered, this
was the
first test personally of using Fortress with BCEL generated proxy
classes in a
SecurityManager environment.

Unfortunately, it failed. In any particular call stack, the
SecurityManager will flag
an error if any individual class does not have permission to perform a

It is possible to grant access to the classes in a particular jar by
placing an entry
like the following in the application's policy file:
grant codeBase "file:../lib/-" {
permission java.security.AllPermission;

This will work for most cases, but when the call stack goes through one of
Fortress's BCelWrapper classes it will fails because the generated class has
not been granted any permissions.

I dug around a bunch and figured out that the only way to get things working
with the currently released version of Fortress is to blindly grant
to all classes as follows:
grant {
permission java.security.AllPermission;

This is obviously not very safe. Especially in my RMI environment, as anyone
could connect and execute malicious code.

I rolled up the sleeves and got to spend a couple days learning more
about the
Java security model than I had initially hoped to. :-/

The problem, I discovered, was that the generated wrapper classes were not
being assigned a java.security.ProtectionDomain. Without a ProtectionDomain,
they did not have a java.security.CodeSource, and without a CodeSource,
was no way to reference the class to be able to assign it a particular
set of
permissions in the policy file.

I thought a while about what a good CodeSource would be for the classes, but
in the end decided that since the classes are wrappers of a particular
the wrapper class could safely have the same permissions as the wrapped

Getting things working turned out to be as simple as modifying the
org.apache.avalon.fortress.impl.factory.BCELWrapperGenerator class to
get the
ProtectionDomain of the class being wrapped and using it when creating
the new
wrapper class.

This has the benefit of making it look like the BCEL generated wrapper class
came from the same jar as the component being wrapped, so its existence can
be completely transparent to the author of a policy file.

I couldn't think of any way that this could open up any security holes,
but it
might me a good idea if someone with more SecurityManager experience
to do a quick code review. The final changes were quite simple.


To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/

View raw message