incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching ...@ops.co.at>
Subject Re: Classmapping and final classes
Date Tue, 22 Jan 2008 08:16:08 GMT
Murray Altheim schrieb:
>
>> In the meantime, for this particular case, I'd recommend that Simon
>> file an enhancement request or bug in JIRA, and folks with embedding
>> expertise (like Murray) can help figure out an approach that would
>> work. If we need to do a little design work for 2.8, great. And if
>> that's doesn't come soon enough for him, he's always got the option
>> of patching the code himself temporarily.
>
> Agreed. I can't see justification for a big, known security hole.
> Patching ClassUtil by removing several 'final' declarations should be
> the province of an individual hack (and a very simple one at that), not
> part of the core. IMO.

Thanks very much to you all for your comments on this so far.

The reason I want to change the behaviour of AuthenticationManager and
AuthorizationManager is that I am trying to embed jspwiki into a webapp
(no ejb) that uses ACEGI security, not jaas. The base classes just do
not support this AFAICT. And the app into which it is to be embedded
also has its own user state and group information. Please note that I
don't know a lot about servlet container security; perhaps there is a
way to configure jaas to map through to ACEGI but if so I don't know it;
I'd rather avoid all that if possible.

Things like UserManager and GroupManager are nicely designed to delegate
through to the UserDatabase and GroupDatabase classes which are
pluggable. I had no need to override the manager classes to customise
these as needed; the database classes were sufficient to give jspwiki
access to the necessary data from the enclosing app.

However the AuthenticationManager and AuthorizationManager encode a lot
of logic and policy into the base classes; overriding just the
Authenticator/Authorizer classes is not enough to get proper control.
Some of the problem behaviour can be turned off by setting
"jspwiki.security=none", which sets the c_useJAAS flag and so skips some
jaas behaviour, but unfortunately it skips too much code.

I don't understand why you would think that a non-final class would be
any less secure than a final one. The reasons for making a class final are:
* so that you don't have to worry about API stability for subclasses
* in order to improve performance

I cannot imagine an attack that would be prevented by making this class
final. I guess someone could provide a plugin that provides a
classmapping.xml file on the classpath. But even then that would have no
effect because these manager classes are all resolved at startup, before
plugins are scanned.

Note that if I have access to the classpath, I can simply place my own
version of this class earlier in the classpath, in which case it
overrides the one that comes with jspwiki anyway. I haven't decided
quite how to manage the use of a patched version of jspwiki yet; I might
even use this approach myself (creating an _jspwiki-patch.jar that
contains modified versions of the problem files, then also including an
unmodified jspwiki.jar file). Providing a "sealed" jar, ie adding
metadata that marks it as a non-extendable package, then digitally
signing the jar, would block this "security hole" but I'm sure you don't
want to go to those lengths.

BTW, it's not final methods in ClassUtil that are the problem, but final
methods in AuthorizationManager and AuthenticationManager.

Regards,

Simon


Mime
View raw message