Re: checking system integrity
On Sat, Feb 10, 2001 at 01:00:32AM -0600, Manoj Srivastava wrote:
> >>"Matt" == Matt Zimmerman <firstname.lastname@example.org> writes:
> Matt> Verifying the database is the easy part; it can be done
> Matt> completely offline, on an isolated system. The hard part is
> Matt> verifying the system against the database, with a definitive
> Matt> answer as to whether anything has changed _or not_.
> Umm. I now have a database whose md5sum i have verified, and I
> also have a md5sum binary I am sure of (since it is on the floppy
> with the keys and all); I verify md5sum and tripwire on my machine;
> run this known good tripwire and md5sum to test and see if this
> system has changed or not.
> What am I missing here? What is the hard part?
Verifying that you are running the program that you think you are running. On
a root-compromised system, you can't even trust the syscall interface to open
the files you expect. It would be a trivial rootkit addition (if it doesn't
exist already) to cause exec()s of binaries named "tripwire" to run a modified
version which reads the same config file, does all the same calculations, but
prints out a successful result regardless of the status of the file.
If the intruder is not very clever, you can catch her with tripwire. If she is
somewhat more clever, you can still catch her with a read-only tripwire
database. But if she is very clever, not even that is enough. Thus, you can
use tripwire to find a compromise, but you cannot trust that a successful
tripwire run indicates that no compromise has taken place.