Re: checking system integrity
On 9 Feb 2001, 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).
this will be a problem with any system though, yes? unless you run it on
a remote box and have it trawl through each byte over the network :P a
write protected floppy sounds like a good place for things you don't want
changed. then again how does it reference the floppy? what's stopping me
from copying the database/exes to r/w media and running them from there?
> 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?
if you have it only reporting problems then disabling it could be as
simple as taking it out of cron (assuming that's where it runs from - i've
never done much more than play with it so i wouldn't know). then again if
it checks itself against the database then the attacker would have to
modify the database and then sign it again. reinitialise the database and
the sysadmin will know because they won't be able to modify it any more
(their password won't work).
> Currently I am compiling tripwire, so I may find answers to some of
> the above when I get it going.
i'd say it's better to go with something that already exists
(tripwire) than start from scratch. no doubt all the things you've raised
have been looked at and solved where possible.
packages include information that may be useful too, although there's
nothing to stop me from modifying the package database itself. i doubt a
tripwire like program based on package management tools would be difficult
to put together.
- samj
Reply to: