On Sat, 12 May 2001, Glenn Nielsen wrote:
> [EMAIL PROTECTED] wrote:
> >
> > If the security manager is not used everything has AllPermissions - the
> > fact that someone can access the internal objects is quite small compared
> > with the fact that it could call System.exit() and read/change any file
> > that tomcat has access to.
>
> Exactly. If you are concerned about security you need to run Tomcat
> with -security so that the Java SecurityManager is used. It doesn't
> make sense to implement code for container security in Tomcat that doesn't
> use the SecurityManager. Why reinvent the wheel?
Glenn,
There are 2 issues here:
1. Introspection code can be used to get around the class loader trick
( that is used to protect the internal classes ). We agree that this is
not a problem in sandboxed configurations, and doesn't matter if
sandboxing is not used ( sandbox==use of SecurityManager ).
2. It may be possible that other mechansims can be used to trick the class
loader - even in sandbox mode. This has been a subject of debate, and I
don't think we know the answer. That's a good reason to use facades ( or
proxy - I think this is the correct term ).
JDK1.3 even has direct support for "dynamic proxy classes" that serve a
similar purpose ( http://java.sun.com/j2se/1.3/docs/guide/reflection/proxy.html ),
and I think we all agree this is an effective protection.
I can agree that in a "strict" VM, the class loader should protect the
internal classes. The "invokevirtual" instruction takes a object reference
( that you have ) _but_ it must "resolve" the method name. That involves
creation of a class with the defining class loader - and should fail.
At least that's my interpretation - but I still believe there is a great
chance that some VMs may cache the resolution results - or maybe some
other tricks could be used.
If someone has the time to write a method to try this - it would be great.
( "normal" code requires a cast to compile - but you can write the
bytecode and just call invokevirtual directly ).
Costin
