On Mon, Jun 25, 2007 at 08:23:21AM -0700, Russ Allbery wrote: > Jim Popovitch <[EMAIL PROTECTED]> writes: > > On Sun, 2007-06-24 at 16:50 +0100, andy baxter wrote: > > >> The difference is that: > > >> a) These all run on the live system they are trying to protect, > > > Unless you configure them to only write to an offline mount point that > > is normally ro and only rw through external effort.... which is in > > Tripwire's best practices. > > That doesn't necessarily help. It makes the attacker's task much more > difficult, but it's still possible to binary-patch a running kernel in > various ways to hide files from everything on the system, including > tripwire. > > You have to boot into a known-clean kernel in order to get a fully > trustable integrity check.
I agree 100%, but ... another way of looking at it is to ask "how hard would this be to break?" There aren't any real world "known clean" kernels, just ones we can reasonably expect not to be infected by a specific problem. just like the compiler thing (reflections on trusting trust), in the real world this has ultimately underwritten by some obstacle course of tough/impossible to follow steps, such as cross-arch compiles and compiles from different compilers, and the expertise and judgment to use this, along with eyes watching for trojans in the source. A similar story no doubt applies with kernels. and then it is all to easy to assume that the underlying hardware is not a problem. but in practice being able to boot from known-clean (eg: read-only media) is a gold-standard weapon in the armoury, and anything that can help join the dots from there to "this installation is clean" is invaluable. Having a strong chain of assurance is important. Regards, Paddy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
