[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-core-dev] Bug 29007: Classloading enhancements for "endorsed" libraries
|
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...