Re: [platform-core-dev] Bug 29007: Classloading enhancements for "endors

[Igor Malinin <igor@xxxxxxxxxxxx>]

Back to the security problems...

John_Arthorne@xxxxxxxxxx wrote:
> I would like to discourage you from taking this route.  A fundamental 
> rule of class loading is that the primordial class loader (the default 
> or system loader) is given the first chance to load classes.  This 
> prevents spoofing of critical classes such as SecurityManager, 
> ClassLoader (which handles byte code verification), etc.  If we added 
>
> http://www.securingjava.com/chapter-two/chapter-two-7.html
> http://java.sun.com/j2se/1.4/docs/guide/security/spec/security-spec.doc5.html 

I have read both and they does not stating anything about loading in 
primordial ClassLoader is a 'fundamental' rule! The second one (and it 
is SPECIFICATION) even doesn't relate standard load ordering to security.

Bellow is a result of my analysis for this problem:

Spoofing such classes as SecurityManager or ClassLoader can't break 
security! Overloaded SecurityManager would be seen only to secure 
sandbox, and critical classes will get right SecurityManager anyway. Any 
ClassLoader can't be created inside secure sandbox, even when spoofed 
because it has to do native call, which is bound to primordial ClassLoader.

On the contrary, overloading of other classes could be really dangerous. 
But this is independent on any class either primordial or from 'safe' 
plugin. But Eclipse already breaks this rule by allowing loading 
plugin's own class before delegating to its dependencies!

This is not only security problem, but usability problem too (you get 
ClassCastException(s) when same class(es) is(are) included in  both 
plugin and its dependency - common problem for many third party 
libraries), but it is a different issue...

When I say overloading I mean exclusion of a number of packages, making 
them invisible to the plugin (and those what depends on it). This will 
greatly simplify implementation and does not change class search 
ordering. Care must be taken by anyone who uses this feature to exclude 
complete integral part of some API. This will prevent possible security 
problems and eliminate ClassCastExceptions.

Since I would introduce overloading only in 'safe' plugins (for 'unsafe' 
plugins disabling declaration of additional excluded packages is 
enough), those 'safe' plugins should care about it's security - just as 
any other plugin which doesn't use overloading!!!


Have you more reasons to discourage me? The only thing could stop me now 
- if my enhancements would newer be accepted for inclusion to Eclipse ;)
Or if you convince me that it is really could break something...