Re: The disappearing sys_call_table export.

[Yoav Weiss]

On Sun, 11 May 2003, Chuck Ebbert wrote:

>   That code has another hole that nobody else has mentioned
> yet: I can fill the audit log by trying to delete nonexistent files,
> and if accused of trying to mount a DOS attack on the audit trail
> I can reasonably claim that it was all an accident...

No one specified what audit_log does in this case.  Usually, in such
modules, the audit function doesn't just log everything.  It can, for
example, rate-limit the logging and just spit a message about the user
DoSing the log system.  If system is paranoid enough to be fail-closed
(i.e. fears that the user is hitting the rate-limit of the logger, hoping
to cover his real acts), it can always kill his task, kill all his
processes, lock his account, call the authorities, etc.  Its up to the
system to decide what audit_log does, just like in any other auditing
system.

>
>   How about:
>
> long wrapped_unlink(char *userfilename)
> {
>         char name1[len], name2[len];
>         long ret;
>
>         copy_from_user(name1, userfilename, ...);
>         ret = original_unlink(userfilename);
>         copy_from_user(name2, userfilename, ...);
>
>         if (strncmp(name1, name2, len))
>                 audit_log(name1, name2, UNLINK_NAME_CHANGED);

Still subject to a timing attack.  The usermode code can change it and
change it back as soon as the file has been unlinked.  If the system is
under heavy load (generated by the attacker), the attacking process is
reniced to 20, and the monitoring part of it has higher priority and keeps
stat(2)ing the file, a thread in the attack code may actually be able to
change the filename back in time for the second check.

The only way to avoid these races is to have just one copy, by either
using set_fs (see my previous post in this thread) or by hooking inside
the syscall (as LSM does).

	Yoav Weiss