Re: [patch] Add basic sanity checks to the syscall execution patch

* pageexec@freemail.hu <pageexec@freemail.hu> wrote:

> On 5 Sep 2008 at 13:42, Ingo Molnar wrote:
> > The other, more fundamental problem that nobody has mentioned so far is 
> > that the check returns -ENOSYS and thus makes rootkit attacks _more 
> > robust_ and hence more likely!
> > 
> > The far better solution would be to insert uncertainty into the 
> > picture: 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.
> 
> there's that adage about history being repeated by those not knowing it ;)
> for details see the series based around bypassing Vista's PatchGuard at:
> 
>   http://uninformed.org/?v=3
>   http://uninformed.org/?v=6
>   http://uninformed.org/?v=8

i think Linux is fundamentally different here as we have the source 
code, and could apply the randomization technique i mentioned:

> > [ It would be nice to have a 'randomize instruction scheduling' 
> >   option for gcc, to make automated attacks that recognize specific 
> >   instruction patterns less reliable. ]

and every box where it matters we could have a _per box_ randomized 
kernel image in essence, with non-essential symbols thrown away, and 
with a few checks inserted in random locations - inlined and in essence 
unrecognizable from the general entropy of randomization.

Not that a randomizing compiler which inserts true, hard to eliminate 
entropy would be easy to implement. But once done, the cat and mouse 
game is over and the needle is hidden in the hay-stack. At least as long 
as transparent rootkits are involved.

a successful attack that wants to disable the checks reliably would have 
to patch the IDT and would have to emulate full kernel execution and 
would have to detect the pattern of an alert on the hardware API level - 
as that would be the only reliably observable output of the system. 
Besides being impractical at best, at minimum a huge slow-down would 
occur.

the only other option would be for a rootkit to transparently switch to 
another, new, non-checked kernel image on the fly, while keeping all 
user-space context safe. That's a feature Linux would like to have 
anyway ;-) [and this could be made really difficult as well if gcc 
inserted a modest amount of per kernel random noise in the layout of all 
data structures / field offsets.]

	Ingo