On Fri, Sep 05, 2008 at 01:42:33PM +0200, Ingo Molnar wrote:
quoted text
> The far better solution would be to insert uncertainty into the picture: 

till there OK :-)

quoted text
> some sort of low-frequency watchdog [runs once a second or so] that 
> tries to hide itself from the general kernel scope as much as possible, 
> perhaps as ELF-PIC code at some randomized location, triggered by some 
> frequently used and opaque kernel facility that an attacker can not 
> afford to block or fully filter, and which would just check integrity 
> periodically and with little cost.

"can not" above is the unrealistic requirement unfortunately.

quoted text
> When it finds a problem it immediately triggers a hard to block/filter 
> vector of alert (which can be a silent alarm over the network or to the 
> screen as well).
> 
> that method does not prevent rootkits in general (nothing can), but sure 
> makes their life more risky in practice - and a guaranteed livelihood 
> and risk reduction is what typical criminals are interested in 
> primarily, not whether they can break into a particular house.
> 
> If we implement it then it should not be present in distro .config's, 
> etc. - it should be as invisible as possible - perhaps only be part of 
> the kernel image .init.data section in some unremarkably generic manner. 

Then they will simply proceed like this :
  - patch /boot/vmlinuz
  - sync
  - crash system

=> user says "oh crap" and presses the reset button. Patched kernel boots.
   Game over. Patching vmlinuz for known targetted distros is even easier
   because the attacker just has to embed binary changes for the most
   common distro kernels.

Clearly all this is a waste of developer time, CPU cycles, memory,
reliability and debugging time. All that time would be more efficiently
spent auditing and debugging existing code to reduce the attack surface,
and CPU cycles + memory would be better spent adding double checks to
most sensible functions' entry points and user data processing.

Regards,
Willy

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/