[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: checking system integrity

On Fri, Feb 09, 2001 at 04:24:31PM +1100, Brian May wrote:

> Then again, looking at tripwire, I can't see what protects the
> tripwire executable from being tampered with either. I don't think it
> is possible unless you can mount it from some media that is guaranteed
> to be read-only (eg write protected floppy disk or read-only exported
> NFS).

You will find that this problem is inherent in any validation mechanism.  The
only way to use a program like tripwire with any kind of assurance is to:

1. Boot the system from known good read-only media
2. Run the tripwire binary (or similar) from similar media
3. Store the database on write-once or write-protectable media
4. Boot the system back into its normal state

These steps must also be taken in order to verify the database with near-100%
assurance.  However, it is still useful to run tripwire against the read-only
database periodically, because it could still catch a change.  But the fact
that tripwire finds nothing cannot be trusted to mean that nothing has been

Another approach might be to use multi-attach storage devices, and have another
(network-isolated) host create, store and validate the database, without using
the shared media for any of its software.

> For example, what is to stop me, as the attacker, from replacing the
> tripwire binary, so that it appears to do all the checks OK, but fails
> to report any differences?

Nothing.  As I said above, tripwire can be used for positive indication of a
change only (except under very artificial conditions, involving downtime), and
not for an indication that nothing has been changed.

 - mdz

Reply to: