On 10 May 2003, Arjan van de Ven wrote:
> On Sat, 2003-05-10 at 16:38, Ahmed Masud wrote:
>
> > Case in point, I wrote a security module for Linux that overrides _all_
> > 237 systemcalls to audit and control the use of the system calls on a per
> > uid basis. (i.e. if the user was actually allowed to make the system call
> > or not) and return -EPERM or jump to system call proper.
>
> I'm pretty sure that auditing by your module can easily be avoided.
>
> examle: pseudocode for the unlink syscall
>
> long your_wrapped_syscall(char *userfilename)
> {
> char kernelpointer[something];
> copy_from_user(kernelpointer, usefilename, ...);
> audit_log(kernelpointer);
> return original_syscall(userfilename);
> }
>
> now.... the original syscall does ANOTHER copy_from_user().
> Eg I can easily fool your logging by having a second thread change the
> filename between the time your code copies it and the time the original
> syscall copies it again. The chances of getting the timing right are 50%
> at least (been there done that ;)
You are right, if operations occur in the sequence above.
What are your thoughts on the following two
A)
long wrapper_call(args) {
yield(random(threshold)); /* yeild is a sleep */
rv = orig_syscall(args...);
copy_from_user(audit_data,args...);
audit_log(audit_data);
return rv;
}
That becomes a bit more difficult to time, because the attacker doesn't
know when the system call will actually perform its own copy_from_user vs.
return vs. the audit's copy_from_user, If the correct upper threshold for
each system call is picked timing attacks can be made alot harder.
B)
long wrapper_call(args) {
yield(random(threshold));
copy_from_user(audit_data1,args...);
rv = orig_syscall(args...);
yield(random(threshold));
copy_from_user(audit_data2,args...);
audit_log(audit_data1);
audit_log(audit_data2);
return rv;
}
Suspicious data analysis is then performed by a user-land tool to
further ensure integrity.
I would just like to say that above does not pretend to be speed happy,
still for practical purposes you can assume that the yield is a lot
shorter (a couple of orders of magnitude) than the duration of the system
call.
Cheers,
Ahmed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/