Verifying that a class hasn't been changed

[James D Carroll]

I'm building a application framework that load classes with
Class.forName().NewInstance. The name would be stored in a database and the
code in a .jar in a directory. When a new class is added to the system I
would like to capture some kind of signature (maybe an MD5 hash of the file)
and store it. Then at runtime I would load the class, get its signature,
and compare it to what's in the database. If they match, then processing
would continue. The reason for this, of course, is to make sure that someone
has not altered the code and slipped it into the system or altered the
classpath to point at their code.

Any suggestions would be greatly appreciated.

 

[Job Numbers]

I'm building a application framework that load classes with
Class.forName().NewInstance. The name would be stored in a database and
the
code in a .jar in a directory. When a new class is added to the system I
would like to capture some kind of signature (maybe an MD5 hash of the
file)
and store it. Then at runtime I would load the class, get its signature,
and compare it to what's in the database. If they match, then processing
would continue. The reason for this, of course, is to make sure that
someone
has not altered the code and slipped it into the system or altered the
classpath to point at their code.

Any suggestions would be greatly appreciated.

This might sound dumb, but if you don't want a class file to change, just
don't give the person the oppurtunity to change it (i.e. adding it in the
database and so on - this seems very bloated). Why not just make the jar
file read only and make sure nobody has the permissions to write over it?
Seems simple enough to me. If the framework can't know the class name in
advance, then it's not really a good framework then is it? I mean, it must
be very generic if you don't even know the kinds of classes that you expect
the framework to take. While I can understand that in some cases you don't
know the class names (subclasses or something like Spring bean factories),
having them in a database just seems like bloat to me.

 

[James D Carroll]

This might sound dumb, but if you don't want a class file to change, just
don't give the person the oppurtunity to change it (i.e. adding it in the
database and so on - this seems very bloated). Why not just make the jar
file read only and make sure nobody has the permissions to write over it?
Seems simple enough to me.

The security requirements require this check, if possible, to be implemented

If the framework can't know the class name in
advance, then it's not really a good framework then is it? I mean, it must
be very generic if you don't even know the kinds of classes that you expect
the framework to take. While I can understand that in some cases you don't
know the class names (subclasses or something like Spring bean factories),
having them in a database just seems like bloat to me.

The framework defines interfaces that other developers would implement in
order to work within the framework.

 

[Job Numbers]

The security requirements require this check, if possible, to be
implemented


The framework defines interfaces that other developers would implement in
order to work within the framework.

if that's the case, then why bother making sure that their classes have
changed? As long as they adhere to the interface, it shouldn't matter. I
don't really understand what is your main problem. I write frameworks all
the time and I've never thought about storing jar files and keeping
signatures for extensions in the database - that just seems very uncessary
to me. In your framework, you should see if a Class/object inherits/is an
instance the interface your framework it expect. If it's not, throw a
specific run time exception and give a good error message why this happened
so the person using the framework knows what the heck happened. If their
class does implement the interface, then proceed.

 

[Roedy Green]

Then at runtime I would load the class, get its signature,

That's what digitally signing a jar does for you automatically.
All you need is a certificate, and jarsigner.

 

[Oscar kind]

That's what digitally signing a jar does for you automatically.
All you need is a certificate, and jarsigner.

Additionally, you may want to seal your packages/jar. This makes sure that
nobody can add replacement classes to the classpath before your jar. This
won't make the replacement classes unavailable, but will make sure that
your code (in the jar file) uses the original classes that you wrote.


kind regards,
Oscar

 

[Roedy Green]

Additionally, you may want to seal your packages/jar. This makes sure that
nobody can add replacement classes to the classpath before your jar. This
won't make the replacement classes unavailable, but will make sure that
your code (in the jar file) uses the original classes that you wrote.

For how, see http://mindprod.com/jgloss/jar.html#SEALING

 

[steve]

This might sound dumb, but if you don't want a class file to change, just
don't give the person the oppurtunity to change it (i.e. adding it in the
database and so on - this seems very bloated). Why not just make the jar
file read only and make sure nobody has the permissions to write over it?
Seems simple enough to me. If the framework can't know the class name in
advance, then it's not really a good framework then is it? I mean, it must
be very generic if you don't even know the kinds of classes that you expect
the framework to take. While I can understand that in some cases you don't
know the class names (subclasses or something like Spring bean factories),
having them in a database just seems like bloat to me.

I can see why he is doing it. it makes rolling out upgrades very easy,
without having to setup a server for "webstart", or as extra security.

You just need to sign & seal the jars, but what yo can also do, (on oracle)
is run the checksum package on the jar.

or you can write a simple checksum package in java & load it into the
database, checksum the java code on loading it into the database, then
checksum it when the client loads it to the local machine.

steve

 

[James D Carroll]

I can see why he is doing it. it makes rolling out upgrades very easy,
without having to setup a server for "webstart", or as extra security.

You just need to sign & seal the jars, but what yo can also do, (on oracle)
is run the checksum package on the jar.

or you can write a simple checksum package in java & load it into the
database, checksum the java code on loading it into the database, then
checksum it when the client loads it to the local machine.

steve

DING DING DING !!!! Steve wins : ) But only the classname, jar path, and
checksum would be stored in the database. I've been looking at the
java.util.jar package and can see where that will be part loading the data
into the database, but its the verifiication at runtime by the client I
can't figure out.

 

[James D Carroll]

Thanks. I'll take a look at it and see if this will satisfy the requirement.
Its coming from Audit/Compliance and given the environment right (Sox 404,
etc) what Compliance wants, Compliance tends to get.