[kaffe] class loading security/compatibility concerns

[Dalibor Topic]

--- gonzo <Robert.N.Gonzalez@williams.edu> wrote:
> Patrick Tullmann wrote:
> > I think you can get Sun's VM to load `A' it if you
> put the path to it
> > on the bootclasspath.  This works for me with
> jdk1.4: 
> >    'java -Xbootclasspath/p:. java.A'
> > 
> > This is also how it knows which jars to verify (or
> not), as I think
> > Sun's VM does what you propose (not veryifying
> system classes).
> 
> in using -Xbootclasspath you're saying "use these
> files in place of the
> boot class files included in the J2SDK and J2RE",
> which means that you
> trust the files quite a bit.  but what if some
> untrested program tries to
> dynamically load a class in some evil package named
> java to trick the VM
> into giving it undeserved permissions (i posted a
> couple weeks ago 
> regarding a situation in the classloader where code
> could get access to
> the system class loader when it otherwise should
> have have had permission
> to do so using the whole "i'm in the java package,
> so treat me different"
> strategy).

I think that the 1.2 class loaders define a package
for a class when the first class in a pakage is
loaded. You can specify if you want the package to be
bound to a specific URL (that comes from the
CodeSource, effectively). That's called "sealing" a
package. If the package is bound to an URL, the class
loader must not allow classes from other URL to
"inject" themselves into the package. I think that all
base classes are by default sealed to the rt.jar and
other system jars where they come from (or should be,
from my point of view). When you use bootclasspath,
you essentially say : "no they are not sealed to a
single URL, they could come from here, too".
Check out
http://java.sun.com/products/jdk/1.2/docs/guide/extensions/spec.html#sealing
for more info on that.

I've got some code for a Package implementation, but I
need to get my CodeSource support in class loaders
cleaned up first. Then these things should fall into
places easily.

> i definitely agree that kaffe should support the
> bootclasspath flag (i'm
> not sure that it does now, though i remember reading
> in one of the FAQs
> that it's not implemented), but in that case we
> would still need some way
> of knowing at run time whether a class came from a
> trusted source, such as
> the runtime libraries or some jar on bootclasspath,
> or an untrusted source
> that requires verification.  in the latter case we
> should probably adhere
> to the way Sun's JVM deals with files in packages
> called java (as well as
> perform full verification, though Sun's JVM appears
> to do most
> verification on files in bootclasspath, aside from
> disallowing new
> packages named java, etc.)

That's what the CodeSource implementation will be good
for, I think (or Class.getProtectiondomain, which
allows you to get the CodeSource along with the
signers).
 
> until we do something like that, anywhere in kaffe
> VM that we check for
> permissions based on belonging to package java or
> kaffe we introduce a
> hole for evildoers.  most particularly in the
> verifier that i'm attempting
> to develop for kaffe.

True. What I have working now is a SystemClassLoader
that extends from URLClassLoader, and creates
CodeSource information for all classes *except* the
classes loaded by the bootstrap loader. I'll need to
put that in the bootstrap loader code, I guess.

> so my question is this: do you guys agree that this
> is something that's
> beneficial for kaffe?  if so, then i can go about
> making the changes to
> the system classloader to make it happen.  i can
> also toss in
> bootclasspath support if we want that soon.

My proposal would be to go with SystemClassLoader that
extends URLClassLoader and add appropriate support in
bootstrap  class loader to create codesource info for
the "system" classes. Once that is working, you need
to add definePackage to ClassLoader (and I've got some
code for that lying around in my half done
kaffe-projects archive ;), and you're set. When the
packages are in, you can do some neat stuff:
implementing full AccessControl for reflection becomes
a piece of cake.

I can send you some code I have lying around if you're
interested.

best regards,

dalibor topic

p.s. sorry for the long delay, I was obsessed with
licensing issues recently ;)

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com