linux-kernel - Re: System call audit

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1210670669.3582.219.camel@pmac.infradead.org>
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/