Messages in this thread |  | | Date | Mon, 15 Jul 1996 23:05:19 +0100 | From | "Stephen C. Tweedie" <> | Subject | Re: Misc Fixes |
| |
Hi, > (I'm generally ignorant about securelevel but ..)
> Couldn't the securelevel shown to a module be a different variable than the > real securelevel? Ie have a function copy the securelevel into a visible > variable, but have the kernel keep it's own copy that actually is used to > determine behavior, (possibly testing to see if the two values disagree)?
All modules have full access to all of kernel memory. If you invent a mechanism to protect some kernel variable then, knowing that mechanism, it would be easy to write module code to compromise it. You have *got* to trust all kernel and module code.
If you are worried about malicious modules, you must either prevent any module from loading, or do kernel-level checks to authenticate modules, which could conceivably be done by using public key authentication or through md5 summing plus a secret key. Public key crypto is probably a bit of overkill for the kernel, but md5 would be easy enough do to and in addition would not violate the US ITAR regulations. The problem would then degenerate into one of protecting the module password, of course, so you are just moving the vulnerability, not removing it. If you really need to permit module loading at run time then it might be a possibility.
Cheers, Stephen. -- Stephen Tweedie <sct@dcs.ed.ac.uk> Department of Computer Science, Edinburgh University, Scotland.
|  |