Protection of Tripwire, such that any attempt to change its configuration by a cracker would be detected, remains a problem, even when a Tripwire itself is protected by a read-only disk. Every protection one can imagine for Tripwire can, of course, be defeated. However, the fact remains that from the time that a cracker gets root on a system, until he shuts down cron or otherwise defeats Tripwire, there is a race in time. This means that a small, specialized system monitoring tool dedicated purely to Tripwire protection which is non-cron-dependent, runs frequently, and is camouflaged to the greatest extent possible, is probably the best bet for winning that race-in-time with a cracker.
The minimum requirements that a comprehensive Tripwire monitor would need, are:
It should be written in a compiled language to make details of what it does difficult for a cracker to ascertain.
It should run at a frequent interval as a daemon that is not dependent on cron.
At startup, it should register with a daemon on a secure host, via an encrypted channel, and check in with that host everytime it runs, so that an alarm can be raised if it disappears.
It must verify the signatures of important system files on which Tripwire depends (e.g. cron and sendmail binaries, and config files which they require), as well as signatures of files in the Tripwire binary directory.
It must verify that important system daemons (e.g. cron and sendmail) are running.
It must verify that a switchable rw/ro disk, if present, was not accidentally left in rw mode by a careless administrator.
It must detect network outages or route loss that would prevent it from reporting via the default network method.
In cases where normal network communication appears to have been lost, it must have a device that is close to write-only from the standpoint of the system CPU (e.g. split-screen system console, raw communication device which cannot be unconfigured, local printer, logging of the console serial line to a remote console manager) in which to log an alarm.