Re: The disappearing sys_call_table export.

Muli Ben-Yehuda
2003-05-10T19:41:16Z

[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]

On Sat, May 10, 2003 at 10:18:34PM +0300, Yoav Weiss wrote:

> Masud, your delay-based solutions won't work because an attack code can
> just keep running in a loop until it gets the timing right. Once is
> enough. Even if it could work, it would have impact on the whole system.
> Afaik, you can't really yield the CPU for very short time slices so you'll
> have to busy-loop instead, and its not acceptable. I believe the below
> solution is the right one. Arjan, please correct me if I'm wrong.
>
> The solution is to have only ONE REAL copy, done by the wrapper. The
> original syscall will copy from a kernel ptr, unknowingly. Consider
> the following modified pseudo-code:
>
> long your_wrapped_syscall(char *userfilename)
> {
> char kernelpointer[something];
> copy_from_user(kernelpointer, usefilename, ...);
> audit_log(kernelpointer);
> old_fs = get_fs();
> set_fs(KERNEL_DS);
> ret = original_syscall(kernelpointer);
> set_fs(old_fs);
> return ret;
> }
>
> userfilename is only copied once. original_syscall just copies
> kernelpointer again, to another kernel pointer. No race.

This approach, while it would solve this particular problem, has a
grave flow. Consider the case where the first copy in the
original_syscall is to copy a user space structure, which has embedded
user space pointers... The set_fs() will cause future
copy_from_user/copy_to_user in original_syscall() calls to succeed
even if the user supplied pointer is in kernel space.

> Removing this symbol will not really get in the way for the bad guys
> because it'll always be possible to find and intercept it anyway (see my
> previous post in this thread), but it'll increase the learning curve for
> kernel newbies. Do we really want that ?

Hear hear.
--
Muli Ben-Yehuda
http://www.mulix.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]