Messages in this thread | | | Subject | Re: System call audit | From | David Woodhouse <> | Date | Tue, 13 May 2008 10:24:29 +0100 |
| |
On Mon, 2008-05-12 at 20:06 -0400, Mathieu Desnoyers wrote: > Hi David, > > As I am looking into the system-wide system call tracing problem, I > start to wonder how auditsc deals with the fact that user-space could > concurrently change the content referred to by the __user pointers.
In general we have to copy the content into kernel space, audit it, and then act on it from there. See the explanation on the IPC audit patch at http://lwn.net/Articles/125350/ for example.
Auditing one thing and then acting on another would be simply broken.
> This would be the case for execve. If we create a program with two > thread; one is executing execve syscalls and the other thread would be > modifying the userspace string containing the name of the program to > execute.
I was going to suggest that that attack vector won't work, because execve() kills all threads. But all you have to do to avoid that is put the data in question into a shared writable mmap and modify it from another _process_. And in fact I suspect there's a combination of CLONE_ flags which would avoid the thread-killing behaviour anyway.
> Since we have two copy_from_user, one in auditsc and one in the > real execve() function, the string passed to the OS could differ from > the string seen by auditsc.
Right. Don't Do That Then. The audit code should see what's _actually_ given to the child process. The audit/execve code has changed since I last looked, but I think it's probably OK because it's reading the contents of the new program's mm on the way back from the execve() system call -- before ever giving the CPU back to that process.
-- dwmw2
| |