Messages in this thread |  | | Date | Fri, 12 Jul 96 23:55:24 EST | From | (Gonzalo Tornaria) | Subject | Re: Misc Fixes |
| |
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> 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>++++
|  |