> It doesnt help. The malicious module does
> unsigned long **ptr=(unsigned long **)&get_securelevel;
> unsigned long *securelevelptr=ptr[SOME_CONSTANT];
> *securelevelptr=0;
Would it be too bad tu run some parts of the kernel (at least modules,
perhaps compiled in drivers too) in protection ring 1? Then you leave ring 0 for
secure compiled-in parts of the kernel. You can't modify page tables from ring
1, can you? You put securelevel (and perhaps some other things) in a read-only
page, and as modules are running in ring 1, they can't write to it.
Perhaps there must be possible to optionally load modules to run at ring 0
if securelevel is sufficient low (could be useful).
I don't know if this is a good idea, or even if it's doable.. may be the
call gate from ring 1 to ring 0 would be too slow... (and it won't be portable,
will it?).
I think that is the only way to *really* avoid writing to securelevel.. If
you are ring 0, you can do anything, right? :-) (if you have a get_securelevel()
function, no matter what complicated it is, you could trace it (?), it could be
made very difficult, but not impossible :)
Another idea, what if we make get_securelevel() polymorfic, randomly choosen
at compile-time; simpler one: put a random number of nop(s) somewhere, and
Alan's trick doesn't work... of course, it's easy to scan the function in this
case, but you can do something "more polymorfic" :)
Saludos,
Gonzalo
GM/CS/S d? a-- C++(+++) UL++(+++)>++++ P++>+++ L+++>++++ E---
W-(+) N+(++) w--- O M-(--) V-(--) PGP(--) b++(+++) G++ e>++++