lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 13 May 2008 10:24:29 +0100 From: David Woodhouse <dwmw2@...radead.org> To: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca> Cc: linux-kernel@...r.kernel.org, mingo@...hat.com Subject: Re: System call audit 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists