Re: The disappearing sys_call_table export.

[Muli Ben-Yehuda <mulix@mulix.org>]

[-- 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 --]