[lkml]   [1996]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Misc Fixes
Alan Cox <> 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" :)


GM/CS/S d? a-- C++(+++) UL++(+++)>++++ P++>+++ L+++>++++ E---
W-(+) N+(++) w--- O M-(--) V-(--) PGP(--) b++(+++) G++ e>++++

 \ /
  Last update: 2005-03-22 13:38    [W:0.030 / U:25.824 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site