Messages in this thread | | | Date | Fri, 20 Aug 1999 09:52:26 +0200 | From | Helge Hafting <> | Subject | RE: Disabling module loading with a module? |
| |
[...] From then on, after every install of a module it checks if any of the >syscall vectors have changed. Have two loadable parameters (WARN_ONLY, >ADDITIONS_ALLOWED) and use these to determine what happens if after a module >install one of the syscalls has changed.
Seems to me you won't gain much if you allow loading and initialization of a module and only rely on a periodic check to see if it messed up the syscall table.
A crack module could do anything during initialization. It could set ADDITIONS_ALLOWED in your module. It could search memory for your stored syscall table and patch that one too. Or you could force crackers to modify something else instead of the syscall table. The obvious crack workaround is to overwrite the syscall destinations adresses instead.
For better module security, allow only modules that is known to be ok. Consider encrypting your modules using pgp or something. Then have the compiled-in module loader decrypt and verify the module before initializing it. A cracker would be unable to produce a new encrypted module or tamper with an existing one.
Not that this would help that much. The root crackers don't need modules, that's merely a convenience for hiding easily. They could replace ps, top, etc. instead. They could replace libc. They could unmount /proc and mount a loop device in its place, with a process updating the now artifical /proc.
Helge Hafting
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |