FEATURES include:

* small memory footprint that doesn't grow during runtime

* uses up-to-date one-way hash algorithms, like the 160-bit Secure
  Hash Algorithm, by way of openssl's crypto library.

* prints checksum of current-state database 

  (important when running unattended, so that the user can verify that
  the new database hasn't been modified since its creation.)

* simple design means a smaller learning curve for users

* clear terminology based on the concept of known state versus current
  state 

* resets file access times after checksumming

* intuitive cascading rulesets for paths in configuration file

* XML output option for easy parsing of integrit's output

* fast compile time

  (not a priority, but a perk of integrit's simplicity ;)


PROC:

Avoid running integrit on /proc or other virtual filesystems that look
like files and really read information from the kernel.

Use a rule in your configuration file like this:

!/proc

... because doing something like 'find /proc -type f | xargs grep foo'
or running integrit on /proc does weird and sometimes bad things.


LIBRARIES:

integrit uses the openssl (http://www.openssl.org/) library for
cryptographic checksums and the Boehm garbage collection library
(http://reality.sgi.com/boehm/gc.html) for memory leak detection, not
for garbage collection, though.  You'll need to be able to do static
linking against your openssl libcrypto library.

Advantages of using openssl include greater peer-review audience of
cryptographic code (lots of people use and scrutinize openssl) and
consequent high-quality code.

The only disadvantages I can think of are that you need a trusted
openssl installation and you need to be able to link statically
against libcrypto (maybe confusing ?).


HOWTO:

There is some information on how to use integrit on the web:

      http://integrit.sourceforge.net/howto.html

usage:

      integrit -C conffile [-x] [-u] [-c]

options:
	
      -C	specify configuration file
      -x	use XML output instead of abbreviated output
      -u	do update: create current state database
      -c	do check: verify current state against known db
      -h	show this help      


CDB:

This distribution includes an unaltered cdb distribution, possible
both by virtue of D.J. Bernstein's generosity and by virtue of cdb's
small code size.

From the cdb homepage at http://cr.yp.to/cdb.html:

    cdb is a fast, reliable, simple package for creating and reading
    constant databases. Its database structure provides several
    features:
    
    	  Fast lookups: A successful lookup in a large database
    	  normally takes just two disk accesses. An unsuccessful
    	  lookup takes only one.

    	  Low overhead: A database uses 2048 bytes, plus 24 bytes per
    	  record, plus the space for keys and data.

    	  No random limits: cdb can handle any database up to 4
    	  gigabytes. There are no other restrictions; records don't
    	  even have to fit into memory. Databases are stored in a
    	  machine-independent format.

    	  Fast atomic database replacement: cdbmake can rewrite an
    	  entire database two orders of magnitude faster than other
    	  hashing packages.

    	  Fast database dumps: cdbdump prints the contents of a
    	  database in cdbmake-compatible format.
    
I'm using cdb because the databases are purported to be more reliable
than Berkley databases, and (more importantly since I don't know that
for myself) cdb databases are about half the size of Berkley
databases. 


CHECKSUM ALGORITHMS:

integrit uses SHA-1 as the only cryptographically-secure checksum
(MDC, or Manipulation Detection Code) algorithm.  That may come as a
surprise to someone who has used tripwire, which has nine or so
algorithms, plus a hook for a user-supplied algorithm.

The reason for this limitation is simple: there is no advantage to
using more than one algorithm.  SHA-1 (Secure Hash Algorithm 1)
produces a 160-bit checksum.  Since there are no known weaknesses in
SHA-1, to find a file with the same checksum as a given file on your
machine with certainty, an attacker would have to make as many
different files with as many different file contents as there are
different values that could fit in a 160-bit binary number (two to the
power of 160).  

On average, though, the attacker would only have to try half as many
times, two to the power of 159.  That number is so mind-whoppingly
huge that the experts agree that such an attack would never work
today.  Someday, big advances in mathematics and hardware capabilities
may make such an attack feasible, but by that time there will be
better checksum algorithms.  

It would be easy to add more algorithms to integrit, but the databases
would be bigger, runtime would be longer, and there would be no gains.
If there were runtime options for the additional algorithms, that
would mean more complexity for the user, again with no additional
benefit.


CONFIGURATION FILE:

integrit requires a configuration file at runtime.  One way to do this
securely is to copy the configuration file to a secure medium (e.g. a
trusted, very tight machine; or a CD-ROM) that is available to the
host where you're running the check (e.g. via read-only NFS or
one-command ssh keys).

(Ask me about one-command ssh keys.  It's a really nice technique if
you're comfortable with ssh.)

The syntax of the file is pretty simple and should be familiar to
users of tripwire and the like.  The known-state database and the
current-state database are specified, as well as the root directory of
the integrit search.  See usr.conf for an example.

Next come rules that govern the way integrit should treat files and
directories it encounters on its search.  An exclamation point means
that the file or directory is passed over entirely.  An equal sign
before a directory means that integrit's search should not descend
into the subdirectories of that directory.

The checks that integrit should perform on a file are given in
one-letter options after the file name.  A lowercase letter turns on a
check and uppercase turns the check off.  e.g., the following lines
mean that the won't be a checksum done on /var/log/messages, but there
will be on /etc/shadow:

     /var/log/messages S
     /etc/shadow s

The default checks are: checksum; inode; permissions; number of links,
uid, gid, mtime, ctime.

Here's a table of letters and the corresponding checks:

        s	checksum
        i	inode
        p	permissions
        l	number of links
        u	uid
        g	gid
        z	file size (redundant if checksums are on)
        a	access time
        m	modification time


CONTACT INFORMATION:

Please write with feedback.  

   Ed L Cashin <ecashin@users.sourceforge.net>

   P.O. Box 2457
   Athens GA 30612

