Verifying that a class hasn't been changed

Discussion in 'Java' started by James D Carroll, Jun 20, 2004.

  1. 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.


    ---
    Outgoing mail is certified Virus Free.
    Checked by AVG anti-virus system (http://www.grisoft.com).
    Version: 6.0.708 / Virus Database: 464 - Release Date: 6/18/2004
    James D Carroll, Jun 20, 2004
    #1
    1. Advertising

  2. James D Carroll

    Job Numbers Guest

    "James D Carroll" <> wrote in message
    news:...
    > 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.
    >
    >
    > ---
    > Outgoing mail is certified Virus Free.
    > Checked by AVG anti-virus system (http://www.grisoft.com).
    > Version: 6.0.708 / Virus Database: 464 - Release Date: 6/18/2004


    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.
    Job Numbers, Jun 20, 2004
    #2
    1. Advertising

  3. "Job Numbers" <>
    > 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.


    ---
    Outgoing mail is certified Virus Free.
    Checked by AVG anti-virus system (http://www.grisoft.com).
    Version: 6.0.708 / Virus Database: 464 - Release Date: 6/19/2004
    James D Carroll, Jun 20, 2004
    #3
  4. James D Carroll

    Job Numbers Guest

    "James D Carroll" <> wrote in message
    news:...
    >
    > "Job Numbers" <>
    >> 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.


    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.
    Job Numbers, Jun 20, 2004
    #4
  5. James D Carroll

    Roedy Green Guest

    On Sun, 20 Jun 2004 00:00:01 -0400, "Job Numbers"
    <> wrote or quoted :

    >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.


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

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
    Roedy Green, Jun 20, 2004
    #5
  6. James D Carroll

    Oscar kind Guest

    Roedy Green <> wrote:
    > On Sun, 20 Jun 2004 00:00:01 -0400, "Job Numbers"
    > <> wrote or quoted :
    >
    >>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.

    >
    > 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

    --
    Oscar Kind http://home.hccnet.nl/okind/
    Software Developer for contact information, see website

    PGP Key fingerprint: 91F3 6C72 F465 5E98 C246 61D9 2C32 8E24 097B B4E2
    Oscar kind, Jun 20, 2004
    #6
  7. James D Carroll

    Roedy Green Guest

    On Sun, 20 Jun 2004 09:06:07 +0200, Oscar kind <> wrote
    or quoted :

    >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

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
    Roedy Green, Jun 20, 2004
    #7
  8. James D Carroll

    steve Guest

    On Sun, 20 Jun 2004 12:00:01 +0800, Job Numbers wrote
    (in article <_Y7Bc.15306$>):

    >
    > "James D Carroll" <> wrote in message
    > news:...
    >> 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.
    >>
    >>
    >> ---
    >> Outgoing mail is certified Virus Free.
    >> Checked by AVG anti-virus system (http://www.grisoft.com).
    >> Version: 6.0.708 / Virus Database: 464 - Release Date: 6/18/2004

    >
    > 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
    steve, Jun 20, 2004
    #8
  9. "steve" <> wrote
    >
    > 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.





    ---
    Outgoing mail is certified Virus Free.
    Checked by AVG anti-virus system (http://www.grisoft.com).
    Version: 6.0.708 / Virus Database: 464 - Release Date: 6/19/2004
    James D Carroll, Jun 21, 2004
    #9
  10. 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.




    "Roedy Green" <> wrote in message
    news:...
    > On Sun, 20 Jun 2004 09:06:07 +0200, Oscar kind <> wrote
    > or quoted :
    >
    > >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
    >
    > --
    > Canadian Mind Products, Roedy Green.
    > Coaching, problem solving, economical contract programming.
    > See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.



    ---
    Outgoing mail is certified Virus Free.
    Checked by AVG anti-virus system (http://www.grisoft.com).
    Version: 6.0.708 / Virus Database: 464 - Release Date: 6/19/2004
    James D Carroll, Jun 21, 2004
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Zach
    Replies:
    6
    Views:
    327
    Kevin Spencer
    Jan 20, 2005
  2. Eric
    Replies:
    2
    Views:
    348
    Jason Kester
    Oct 25, 2005
  3. jb
    Replies:
    7
    Views:
    423
    Spartanicus
    Sep 15, 2005
  4. Wolfgang Grafen
    Replies:
    5
    Views:
    416
    Kent Johnson
    Dec 24, 2005
  5. Tony Burden

    Using a define that hasn't been #defined

    Tony Burden, Aug 23, 2010, in forum: C Programming
    Replies:
    5
    Views:
    359
    Tom St Denis
    Aug 24, 2010
Loading...

Share This Page