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

* 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 [-u] [-c]

options:
	
      -C	specify configuration file
      -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. 


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

