Simon Kitching wrote:
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.
Understood.
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.
If you're doing a major overhaul of JSPWiki's authentication and authori-
zation it would seem that taking the existing AuthenticationManager and
AuthorizationManager classes as starting points and rewriting them (not
extending the existing) as necessary would be the way forward. Then,
using the existing feature of the ClassUtil (without modification), you
add your class mappings to ClassUtil's classmappings.xml file:
public static final String MAPPINGS = "/ini/classmappings.xml";
then let WikiEngine instantiate them using the existing code:
m_authenticationManager = (AuthenticationManager)
ClassUtil.getMappedObject(AuthenticationManager.class.getName());
m_authorizationManager = (AuthorizationManager)
ClassUtil.getMappedObject( AuthorizationManager.class.getName());
I don't see how a modification of ClassUtil is necessary here. The real
grunt work is rewriting the two AA classes. But so far as I understand
your requirements, the existing machinery permits this.
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
Making a class final is also simply to prevent extension (which is true
for APIs as well as any other class uses). One of the principal reasons
to prevent extension is for security.
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.
It's a general purpose utility that has by its nature the ability to
alter which classes are instantiated at any given time -- that in itself
is great opportunity for cracking into a wiki, from all sorts of angles.
It's just IMO not the kind of tool one would want to leave open to abuse.
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.
As you point out, there's no security issue there because all of that
occurs either during installation or as the wiki is firing up. But I've
never needed to go to any of those lengths myself. You might investigate
the cascading property feature as well as ClassUtil.MAPPINGS if you haven't
already.
BTW, it's not final methods in ClassUtil that are the problem, but final
methods in AuthorizationManager and AuthenticationManager.
Yes, but you probably just need to rewrite those classes anyway since
you're not using the same AA model. Perhaps I'm not understanding where
the problem really is, i.e., it would seem to be a case of rewriting
those two classes and setting the mappings so that ClassUtil instantiates
your rewritten classes rather than the existing two.
Murray
...........................................................................
Murray Altheim <murray07 at altheim.com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
